[Python-Dev] PEP 3147: PYC Repository Directories

[Brett Cannon]

On Wed, Feb 3, 2010 at 13:33, "Martin v. Löwis" <martin at v.loewis.de> wrote:

> Guido van Rossum wrote:
> > On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >> On the issue of __file__, I'd suggesting not being too hasty in
> >> deprecating that in favour of __source__. While I can see a lot of value
> >> in having it point to the source file more often with a different
> >> attribute that points to the cached file, I don't see a lot of gain to
> >> compensate for the pain of changing the name of __file__ itself.
> >
> > Can you clarify? In Python 3, __file__ always points to the source.
> > Clearly that is the way of the future. For 99.99% of uses of __file__,
> > if it suddenly never pointed to a .pyc file any more (even if one
> > existed) that would be just fine. So what's this talk of switching to
> > __source__?
>
> I originally proposed it, not knowing that Python 3 already changed the
> meaning of __file__ for byte code files.
>
> What I really wanted to suggest is that it should be possible to tell
> what gets really executed, plus what source file had been considered.
>
> So if __file__ is always the source file, a second attribute should tell
> whether a byte code file got read (so that you can delete that in case
> you doubt it's current, for example).
>
>
What should be done for loaders? Right now we have get_filename() which is
what __file__ is to be set to. For importlib there is source_path and
bytecode_path, but both of those are specified to return None in the cases
of source or bytecode are not available, respectively.

The bare minimum, I think, is we need loaders to have mehod(s) that return
the path to the source -- whether it exists or not, to set __file__ to --
and the path to bytecode if it exists -- to set __compiled__ or whatever
attribute we come up with. That suggests to me either two new methods or one
that returns a two-item tuple. We could possibly keep get_filename() and say
that people need to compare its output to what source_path()-equivalent
method returns, but that seems bad if the source location needs to be based
on the bytecode location.

My thinking is we deprecate get_filename() and introduce some new method
that returns a two-item tuple (get_paths?). First item is where the source
should be, and the second is where the bytecode is if it exists (else it's
None). Putting both calculations into a single method seems better than a
source_path()/bytecode_path() as the latter would quite possibly need
source_path() to call bytecode_path() on its own to calculate where the
source should be if it doesn't exist on top of the direct call to
get_bytecode() for setting __compiled__ itself.

-Brett




> Regards,
> Martin
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100204/baf2ee14/attachment.htm>