On Jun 12, 2012 6:24 PM, "fwierzbi...@gmail.com" <fwierzbi...@gmail.com> wrote: > > On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon <br...@python.org> wrote: > > > > > > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow <ericsnowcurren...@gmail.com> > > wrote: > >> > >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon <br...@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
_______________________________________________ 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