v+python at g.nevcal.com
Sat Feb 27 06:03:30 CET 2010
On approximately 2/26/2010 8:31 PM, came the following characters from
the keyboard of Brett Cannon:
> I'm not sure why what you did is different than what I did,
> -M uses runpy which is not directly equivalent to importing.
OK, that gives me some good keywords for searching documentation. What
I (thought I) knew so far, was that it seemed to be equivalent, but that
could easily be the 10,000' view instead of the reality. Thanks.
> nor why you state without justification that it shouldn't work...
> It just is not supposed to happen that way. Masquerading a bytecode
> file as a source file shouldn't work; imp.get_suffixes() controls how
> files should be interpreted based on their file extension.
Well, since a .py can be a .zip, why not a .pyc? Just because no one
thought of doing it before?
Of course, I realize that I only know that a .py can be a .zip on the
command line (is that runpy again, I'll bet it is), not for importing,
which probably doesn't work, from what you imply. But if the technique
can work from the command line, it seems the same technique could be
re-used in the importer. A bytecode only .py would result in identical
values for __file__ and __cached__ methinks.
Glenn -- http://nevcal.com/
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
More information about the Python-Dev