On Wed, Feb 3, 2010 at 14:40, Michael Foord <fuzzy...@voidspace.org.uk>
wrote:
> On 03/02/2010 22:05, Brett Cannon wrote:
>>
>> On Wed, Feb 3, 2010 at 13:52, Nick Coghlan<ncogh...@gmail.com>  wrote:
>>
>>>
>>> Brett Cannon wrote:
>>>
>>>>
>>>> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou<solip...@pitrou.net>
>>>>  wrote:
>>>>
>>>>>
>>>>> Barry Warsaw<barry<at>  python.org>  writes:
>>>>>
>>>>>>
>>>>>> Python 3 uses the .py file for __file__ but I'd like to see a
>>>>>> transition to
>>>>>> __source__ for that, with __cache__ for the location of the PVM, JVM,
>>>>>> LLVM or
>>>>>> whatever compilation cache artifact file.
>>>>>>
>>>>>
>>>>> Well, I don't think we need another transition... Just keep __file__
>>>>> for the
>>>>> source file, and add a __cache__ or __compiled__ attribute for the
>>>>> compiled
>>>>> file(s).
>>>>>
>>>>
>>>> So what happens when only bytecode is present? As of right now
>>>> __file__ is set to the path of the bytecode if no source exists
>>>> (needed for reloading along with backwards-compatibility). Would you
>>>> set __file__ = __compiled__? Or would __file__ be set to None? I am
>>>> going to assume the former for backwards-compatibility, but I figured
>>>> I would bring up the issue as it means getting only the source path
>>>> would become ``__file__ if __file__ != __compiled__ else None``.
>>>>
>>>
>>> My suggestion was that __file__ be set to the expected location of the
>>> source file regardless of whether or not the source file actually
>>> exists. Given the new location of the compiled files under PEP 3147
>>> there is no 100% backwards compatible option for __file__ in this case,
>>> since they will be at a different depth in the directory hierarchy.
>>>
>>>
>>
>> But what does "expected location" mean? If I am importing foo.bar
>> where foo.__path__ has multiple path entries, which one is supposed to
>> be used to set the hypothetical location of source for __file__? I
>> guess going with the first one would be somewhat reasonable, but it's
>> definitely a guess.
>>
>
> Isn't __file__ usually baked into .pyc files at compile time? (At least I
> assumed that from the incorrect tracebacks on Windows when you ship just
> .pyc files.)

Yes, but import.c back-patches before loading to get around this. This will
eventually get fixed, though: see http://bugs.python.org/issue6811 .

-Brett


>
> Michael
>
>
>> -Brett
>>
>>
>>
>>>
>>> Reload can easily enough be updated to fall back to __compiled__ if
>>> __file__ is missing, which is a much easier fix than trying to update
>>> any third party manipulations of __file__ that expect it to be pointing
>>> to a file in the same directory as the source file.
>>>
>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>>
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf
of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release
me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
>
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to