[Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

[Brett Cannon]

On Jun 12, 2012 6:24 PM, "fwierzbicki at gmail.com" <fwierzbicki at gmail.com>
wrote:
>
> On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow <ericsnowcurrently at gmail.com>
> > wrote:
> >>
> >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon <brett at python.org>
wrote:
> >> > I should mention another option is to add sys.dont_read_bytecode (I
> >> > think I
> >> > have discussed this with Frank at some point).
> >>
> >> Or check for "sys.implementation.cache_tag is None"...
> >
> >
> > Perfect! Will that work for Jython (Franke) and IronPython (Jeff)?
> So Jython does actually emit bytecodes, but they are Java bytecodes
> instead of Python bytecodes. Right now they end up next to the .py
> files just like .pyc files. They have the possibly unfortunate naming
> foo.py -> foo$py.class -- If I understand cache_tag (I may not) I
> guess Python 3 is putting the .pyc files into hidden subdirectories
> instead of putting them next to the .py files?

Yes, __pycache__. The tag is to allow different versions of bytecode to
exist side-by-side (eg for CPython 3.3 it's cpython33 so the file ends up
being named foo-cpython33.pyc).

If so we may do the
> same with our $py.class files.

That was part of the hope when it was designed.

>
> Incidentally we also have a mode for reading .pyc files -- though we
> haven't implementing writing them yet (we probably will eventually)

If you can read .pyc files then you should be fine.

>
> I guess what I'm trying to say is that I don't know exactly how we
> will handle these new flags, but chances are we will use them (Again
> provided my guesses about what they do are anywhere near what they
> really do).

IOW it's too soon to be having this discussion. :) I mean regardless of
what happens you can always tweak the import lib code as necessary, I just
wanted to try to avoid it.

>
> >
> > This does mean, though, that imp.cache_from_source() and
> > imp.source_from_cache() might need to be updated to raise a reasonable
> > exception when sys.implementation.cache_tag is set to None as I believe
> > right now it will raise a TypeError because None isn't a str. But what
to
> > raise instead? TypeError? EnvironmentError?
> NotImplementedError seems fine for me too if we don't end up using this
flag.

OK, that's 2 votes for that exception.

>
> -Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120612/875f3967/attachment.html>