[Python-Dev] __file__

[Brett Cannon]

On Fri, Feb 26, 2010 at 20:08, Glenn Linderman
<v+python at g.nevcal.com<v%2Bpython at g.nevcal.com>
> wrote:

> 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
>> details
>>
>> -Brett
>>
>
> 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
> 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.

-Brett



> 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...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100226/d9e43d1d/attachment.html>