[Patches] [ python-Patches-642578 ] Expose PyImport_FrozenModules in imp
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 29 Nov 2002 04:33:51 -0800
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-29 13:33
Message:
Logged In: YES
user_id=92689
I'm ready to commit this. Any objections?
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2002-11-26 01:53
Message:
Logged In: YES
user_id=92689
Anticipating acceptance of this patch, I've checkin in
actual (but optional) employment of imp.set_frozenmodules()
in Mac/Lib/bundlebuilder.py.
The neat thing about this is that bootstrapping happens in a
custom "site" module: I don't even have to wrap the main
program...
----------------------------------------------------------------------
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