On 11/5/06, Steve Holden <[EMAIL PROTECTED]> wrote:
Yep. The main point of this rewrite is to refactor the built-in importers to be PEP 302 importers so that they can easily be left out to protect imports. Plus I have made sure that doing something like .ptl files off the filesystem is simple (a subclass with a single method overloaded) or introducing a DB as a back-end store (should only require the importer/loader part; can even use an existing class to handle whether bytecode should be recreated or not).
Since a DB back-end is a specific use-case I even have notes in the module docstring stating how I would go about doing it.
-Brett
[Off-list]
Brett Cannon wrote:
[...]
>
> Hopefully my import rewrite is flexible enough that people will be able
> to plug in their own importer/loader for the filesystem so that they can
> tune how things like this are handled ( e.g., caching what files are in a
> directory, skipping bytecode files, etc.).
>
I just wondered whether you plan to support other importers of the PEP
302 style? I have been experimenting with import from database, and
would like to see that work migrate to your rewrite if possible.
Yep. The main point of this rewrite is to refactor the built-in importers to be PEP 302 importers so that they can easily be left out to protect imports. Plus I have made sure that doing something like .ptl files off the filesystem is simple (a subclass with a single method overloaded) or introducing a DB as a back-end store (should only require the importer/loader part; can even use an existing class to handle whether bytecode should be recreated or not).
Since a DB back-end is a specific use-case I even have notes in the module docstring stating how I would go about doing it.
-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
