brett at python.org
Sat Feb 27 05:31:56 CET 2010
On Fri, Feb 26, 2010 at 20:08, Glenn Linderman
<v+python at g.nevcal.com<v%2Bpython at g.nevcal.com>
> On approximately 2/26/2010 5:13 PM, came the following characters from the
> keyboard of Brett Cannon:
> On Fri, Feb 26, 2010 at 15:35, Glenn Linderman <v+python at g.nevcal.com<v%2Bpython at g.nevcal.com><mailto:
>> v%2Bpython at g.nevcal.com <v%252Bpython at g.nevcal.com>>> wrote:
>> On approximately 2/26/2010 2:55 PM, came the following characters
>> from the keyboard of Brett Cannon:
>> Maybe Greg's and my response to the mention of dropping
>> this feature
>> is too strong -- after all we're both dinosaurs. And maybe the
>> developers who want the feature can write their own loader.
>> We could also provide if necessary.
>> So if the implementation stores .pyc by default in a
>> version-specific place, then it seems there are only two things
>> needed to make a python byte-code only distribution...
>> 1) rename all the .pyc to .py
>> 2) packaging
>> When a .pyc is renamed to .py, Python (3.1 at least) recognizes
>> and uses it... I assume by design, rather than accident, but I
>> don't know the history.
>> This does not work for me (nor should it):
>> > touch temp.py
>> > python3 -c "import temp"
>> > rm temp.py
>> > mv temp.pyc temp.py
>> > python3 -c "import temp"
>> Traceback (most recent call last):
>> File "<string>", line 1, in <module>
>> File "temp.py", line 2
>> SyntaxError: Non-UTF-8 code starting with '\x95' in file temp.py on line
>> 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for
> I'll admit to not doing exhaustive testing, but I'll not admit to not doing
> any testing... because it was sort of a wild idea. Someone else called it
> "kooky", which is fair.
> What I did was:
> python -m test
> ren test.pyc foo.py
> and it worked. Then I posted, knowing that I'd also tested, the other day,
> several .py into a .zip named .py, and once that worked, then I changed to
> putting all .pyc into the .zip named .py and that worked too... including
> imports of the several modules from the "__main__.pyc". Of course, all
> those were still named .pyc inside the .zip named .py.
> So I'm not sure what the difference is... .pyc as .py works from the
> command line, but not from import? Some specialty because of using -c ?
> I'd guess the technique could be made to work, probably not require
> extensive changes, if Python developers wanted to make it work. I think it
> could be efficient and that same someone that called it "kooky" admitted it
> would solve their use case, at least.
> I'm not sure why what you did is different than what I did,
-M uses runpy which is not directly equivalent to importing.
> 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.
> I might be able to figure out the former if I spend enough time with the
> documentation, if it is documented, but I'm too new to Python to understand
> the latter without explanation. Could you supply at least the latter
> explanation? I'd like to understand the issue here, whether or not the
> "kooky" idea goes forward.
> Glenn -- http://nevcal.com/
> A protocol is complete when there is nothing left to remove.
> -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev