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

[fwierzbicki at gmail.com]

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? If so we may do the
same with our $py.class files.

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

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).

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

-Frank