RetroSearch Browse

Thu Jul 20 19:09:07 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-July/067583.html

On 7/20/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060720/32151d26/attachment-0001.htm 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-July/067583.html below:

[Python-Dev] new security doc using object-capabilities