On Wed, 13 Jun 2012 11:20:24 -0700, Toshio Kuratomi <a.bad...@gmail.com> wrote: > On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote: > > > > OK, but you didn't answer the question :). If I understand correctly, > > everything you said applies to *writing* the bytecode, not reading it. > > > > So, is there any reason to not use the .pyo file (if that's all that is > > around) when -O is not specified? > > > > The only technical reason I can see why -O should be required for a .pyo > > file to be used (*if* it is the only thing around) is if it won't *run* > > without the -O switch. Is there any expectation that that will ever be > > the case? > > > Yes. For instance, if I create a .pyo with -OO it wouldn't have docstrings. > Another piece of code can legally import that and try to use the docstring > for something. This would fail if only the .pyo was present.
Yes, but that's not what I'm talking about. I would treat code that depends on the presence of docstrings and doesn't have a fallback for dealing with there absence as buggy code, since anyone might decide to run that code with -OO, and the code would fail in that case too. I'm talking about a case where the code runs correctly with -O (or -OO), but fails if the code from the .pyo is loaded and python is run *without* -O (or -OO). > Of course, it would also fail under the present behaviour since no .py or > .pyc was present to be imported. The error that's displayed might be > clearer if we fail when attempting to read a .py/.pyc rather than failing > when the docstring is found to be missing, though. Well, right now if there is only a .pyo file and you run python without -O, you get an import error. The question is, is that the way we really want it to work? --David _______________________________________________ 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
