<br><br><div><span class="gmail_quote">On 9/27/06, <b class="gmail_sendername">Phillip J. Eby</b> <<a href="mailto:pje@telecommunity.com">pje@telecommunity.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;">
At 05:26 PM 9/27/2006 -0700, Brett Cannon wrote:<br>>Ah, OK. So for importing 'email', the zipimporter would call the .pyc<br>>importer and it would ask the zipimporter, "can you get me email.pyc?" and<br>
>if it said no it would move on to asking the .py importer for email.py, etc.<br><br>Yes, exactly.<br><br><br>>That's fine. Just thinking about how the current situation sucks for NFS<br>>but how caching just isn't done. But obvoiusly this could change.
<br><br>Well, with this design, you can have a CachingFilesystemImporter as your<br>storage mechanism to speed things up.<br><br><br>>> >>Of course, to fully support .pyc timestamp checking and writeback, you'd
<br>>> >>need some sort of "stat" or "getmtime" feature on the parent importer, as<br>>> >>well as perhaps an optional "save_data" method. These would be extensions<br>
>> >>to PEP 302, but welcome ones.<br>>> ><br>>> >Could pass the string representing the location of where the string came<br>>> >from. That would allow for the required stat calls for .pyc files as
<br>>> >needed without having to implement methods just for this one use case.<br>>><br>>>Huh? In order to know if a .pyc is up to date, you need the st_mtime of<br>>>the .py file. That can't be done in the parent importer without giving it
<br>>>format knowledge, which goes against the point of the exercise.<br>><br>>Sorry, thought .pyc files based whether they needed to be recompiled based<br>>on the stat info on the .py and .pyc file, not on data stored from within
<br>>the .pyc .<br><br>It's not just that (although I believe it's also the case that there is a<br>timestamp inside .pyc), it's that to do the check in the parent importer,<br>the parent importer would have to know that there is such a thing as
<br>.py-and-.pyc. The whole point of this design is that the parent importer<br>doesn't have to know *anything* about filename extensions OR how those<br>files are formatted internally. In this scheme, adding more child
<br>importers is sufficient to add all the special handling needed for<br>.py/.pyc-style schemes.<br><br>Of course, for maximum flexibility, you might want get_stream() and<br>get_file() methods optionally available, since a .so loader really needs a
<br>file, and .pyc might want to read in two stages. But the child importers<br>can be defensively coded so as to be able to live with only a<br>parent.get_data(), if necessary, and do the enhanced behaviors only if<br>stat() or get_stream() or write_data() etc. attributes are available on the
<br>parent.</blockquote><div><br>Yeah, how to get the proper information to the data importers is going to be the trick. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If we get some standards for these additional attributes, we can document<br>them as standard PEP 302 extensions.<br><br>The format importer mechanism might want to have something like<br>'sys.import_formats' as a list of importer classes (or factories). Parent
<br>(storage) importer classes would then create instances to use.<br><br>If you add a new format importer to sys.import_formats, you would of course<br>need to clear sys.path_importer_cache, so that the individual importers are
<br>rebuilt on the next import, and thus they will create new child importer<br>chains.<br><br>Yeah, that pretty much ought to do it.</blockquote><div><br><br>I will think about it, but I am still trying to get the original question of how bad the C code is compared to rewriting import in Python from people. =)
<br><br>-Brett <br></div><br></div>