<p><br>
On Jun 12, 2012 6:24 PM, "<a href="mailto:fwierzbicki@gmail.com">fwierzbicki@gmail.com</a>" <<a href="mailto:fwierzbicki@gmail.com">fwierzbicki@gmail.com</a>> wrote:<br>
><br>
> On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> ><br>
> ><br>
> > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>><br>
> > wrote:<br>
> >><br>
> >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> >> > I should mention another option is to add sys.dont_read_bytecode (I<br>
> >> > think I<br>
> >> > have discussed this with Frank at some point).<br>
> >><br>
> >> Or check for "sys.implementation.cache_tag is None"...<br>
> ><br>
> ><br>
> > Perfect! Will that work for Jython (Franke) and IronPython (Jeff)?<br>
> So Jython does actually emit bytecodes, but they are Java bytecodes<br>
> instead of Python bytecodes. Right now they end up next to the .py<br>
> files just like .pyc files. They have the possibly unfortunate naming<br>
> foo.py -> foo$py.class -- If I understand cache_tag (I may not) I<br>
> guess Python 3 is putting the .pyc files into hidden subdirectories<br>
> instead of putting them next to the .py files?</p>
<p>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).</p>
<p> If so we may do the<br>
> same with our $py.class files.</p>
<p>That was part of the hope when it was designed.</p>
<p>><br>
> Incidentally we also have a mode for reading .pyc files -- though we<br>
> haven't implementing writing them yet (we probably will eventually)</p>
<p>If you can read .pyc files then you should be fine.</p>
<p>><br>
> I guess what I'm trying to say is that I don't know exactly how we<br>
> will handle these new flags, but chances are we will use them (Again<br>
> provided my guesses about what they do are anywhere near what they<br>
> really do).</p>
<p>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.</p>
<p>><br>
> ><br>
> > This does mean, though, that imp.cache_from_source() and<br>
> > imp.source_from_cache() might need to be updated to raise a reasonable<br>
> > exception when sys.implementation.cache_tag is set to None as I believe<br>
> > right now it will raise a TypeError because None isn't a str. But what to<br>
> > raise instead? TypeError? EnvironmentError?<br>
> NotImplementedError seems fine for me too if we don't end up using this flag.</p>
<p>OK, that's 2 votes for that exception.</p>
<p>><br>
> -Frank<br>
</p>