[Patches] [ python-Patches-642578 ] Expose PyImport_FrozenModules in imp

[noreply@sourceforge.net]

Patches item #642578, was opened at 2002-11-22 23:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642578&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expose PyImport_FrozenModules in imp

Initial Comment:
The attached patch exposes the PyImport_FrozenModules
global variable. It can be written through the new
imp.set_frozenmodules() function. No read functionality
has been provided since that would be harder to do
<wink>, and would IMO not be all that useful.

Rationale:
It allows py2exe/McMillan-Installer-like tools to be
written WITHOUT __import__ hooks, while still being
able to bootstrap with pure Python code.

Use case:
I'm in the process of writing a freeze-like tool for
MacOSX. Applications on this platform are (usually)
simply a directory containing some meta files and
arbitrary stuff. I can (and will) make it simply add
.pyc files to this directory, but it will be a huge win
to be able to put a single file in there containing all
needed Python modules. I would prefer to do this
without resorting to __import__ hooks, as they add
overhead and brittleness. I use a vanilla python
executable and bootstrap in Python. Look ma, no C!

Implementation:
PyImport_FrozenModules is an array of structs
containing a pointer to a C string (the name), a
pointer to the marshalled code object data and an int
specifying the size of the code data (negated if the
module is a package). None of these are Python objects.
imp.set_frozenmodules() takes a sequence of tuples as
its argument: (name, codedata, ispkg). Internally this
sequence is converted to a tuple, and a reference is
kept in an additional static variable in import.c. The
elements of the newly allocated PyImport_FrozenModules
array simply point to the actual string data, as
referenced by the tuple.

The patch doesn't include documentation yet, but I will
add that as soon as the patch is otherwise accepted.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-11-25 20:29

Message:
Logged In: YES 
user_id=92689

[raise error on overwrite]
No, for one because it is always set (see Python/frozen.c or
do "import __hello__" ;-). Also: it _might_ be useful to
extend the list by first retrieving is, appending to it and
setting it again.

The other "issue": let's make that an issue when rewriting
the entire import stuff is an active project... (It would
also involve a C API to set/modify the frozen modules list,
which, erm, perhaps should be a dict anyway, and and...)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-11-25 20:22

Message:
Logged In: YES 
user_id=11105

Hm, shouldn't overwriting the frozen module table, if it is 
already set, raise an error?

Or should there be more than one frozen tables?

And having said that, I could even think of situations where 
the frozen module tables should be private to *one* 
interpreter, and not be shared if there have been other ones 
created by Py_NewInterpreter. But this issue should probably 
left for a separate patch ;-)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-11-25 09:52

Message:
Logged In: YES 
user_id=11105

I haven't actually tried out the patch, but it looks fine to me.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-11-24 00:26

Message:
Logged In: YES 
user_id=92689

Yes, done in the replaced patch.

I've also changed a subtlety in get_frozenmodules(): the
previous version returned the original tuple as it was set
by set_frozenmodules(), now it always builds the tuple from
scratch: it's possible that someone changes
PyImport_FrozenModules from C, invalidating the cached tuple.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-23 23:14

Message:
Logged In: YES 
user_id=21627

Can you provide a patch for libimp.tex as well?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-11-23 01:35

Message:
Logged In: YES 
user_id=92689

Ok, I changed my mind and created a matching
imp.get_frozenmodules() function that _returns_ a Python
representation of PyImport_FrozenModules. Replaced the patch.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-11-23 00:21

Message:
Logged In: YES 
user_id=92689

(doop: the first patch I uploaded contained a syntax error.
How embarrassing... The current file is correct.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642578&group_id=5470