<br><br><div><span class="gmail_quote">On 11/5/06, <b class="gmail_sendername">Steve Holden</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[Off-list]<br>Brett Cannon wrote:<br>[...]<br>><br>> Hopefully my import rewrite is flexible enough that people will be able<br>> to plug in their own importer/loader for the filesystem so that they can<br>> tune how things like this are handled (
e.g., caching what files are in a<br>> directory, skipping bytecode files, etc.).<br>><br>I just wondered whether you plan to support other importers of the PEP<br>302 style? I have been experimenting with import from database, and
<br>would like to see that work migrate to your rewrite if possible.</blockquote><div><br>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).
<br></div><br>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.<br><br>-Brett</div>