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
