[Python-Dev] #12982: Should -O be required to read .pyo files? (original) (raw)

R. David Murray rdmurray at bitdance.com
Wed Jun 13 20:57:35 CEST 2012

On Wed, 13 Jun 2012 11:20:24 -0700, Toshio Kuratomi <a.badger at 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

More information about the Python-Dev mailing list