On 7/20/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Right, but some people like to construct directly from bytecode.
I figured as much, but when I was making the list I was not sure and didn't want to stop my writing momentum to check.
Yep. Plan on looking at all of the various modules in the stdlib that assist with importing, package PEP (I think there is one), and PEP 302.
Ah, OK.
Yep. I just kind of glanced at the rest of your suggestions, Nick, since I assumed a lot of it would change (or could be changed) if import was redone in as much Python as possible.
Yep. Although I am more interested in restricting than broadening the file types.
Maybe. I don't want to get into introducing new abilities to start, though.
-Brett
For code objects, their construction is already commonly written as
"compile(source)".
Right, but some people like to construct directly from bytecode.
For type objects, the constructor doesn't let you do anything you can't
already do with a class statement. It doesn't need securing.
I figured as much, but when I was making the list I was not sure and didn't want to stop my writing momentum to check.
For rewriting import.c in Python, the PEP 302 compliant import system API in
pkgutil would be a good starting point.
Yep. Plan on looking at all of the various modules in the stdlib that assist with importing, package PEP (I think there is one), and PEP 302.
Your doc also asks about the imp.get_suffixes() list, and wonder where to set
it from Python.
As far as I am aware, you can't. get_suffixes() is built from
_PyImport_FileTab, which is a C array. A switch statement is used to get from
the file table entries to the appropriate handler functions.
Ah, OK.
Quoting from the suggestions I put to the Py3k list:
Use smarter data structures
---------------------------
Currently, the individual handlers to load a fully identified module are
exposed to Python code in a way that reflects the C-style data structures used
in the current implementation.
Simply switching to more powerful data structures for the file type handlers
(i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, and
a PyDict instead of a switch statement to go from filedescr values to module
loading/initialisation functions) and manipulating them all as normal Python
objects could make the code in import.c much easier to follow.
Yep. I just kind of glanced at the rest of your suggestions, Nick, since I assumed a lot of it would change (or could be changed) if import was redone in as much Python as possible.
Extensible file type handling
-----------------------------
If the file type handlers are stored in normal Python data structures as
described above, it becomes feasible to make the import system extensible to
different file types as well as to different file locations.
Yep. Although I am more interested in restricting than broadening the file types.
This could be handled on a per-package basis, e.g. via a __file_types__
special attribute in packages.
Maybe. I don't want to get into introducing new abilities to start, though.
-Brett
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
