[Python-Dev] #12982: Should -O be required to *read* .pyo files?

Brett Cannon brett at python.org
Wed Jun 13 19:19:43 CEST 2012


On Tue, Jun 12, 2012 at 2:16 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> http://bugs.python.org/**issue12982 <http://bugs.python.org/issue12982>
>
> Currently, cpython requires the -O flag to *read* .pyo files as well as
> the write them. This is a nuisance to people who receive them from others,
> without the source. The originator of the issue quotes the following from
> the doc (without giving the location).
>
> "It is possible to have a file called spam.pyc (or spam.pyo when -O is
> used) without a file spam.py for the same module. This can be used to
> distribute a library of Python code in a form that is moderately hard to
> reverse engineer."
>
> There is no warning that .pyo files are viral, in a sense. The user has to
> use -O, which is a) a nuisance to remember if he has multiple scripts and
> some need it and some not, and b) makes his own .py files used with .pyo
> imports cached as .pyo, without docstrings, like it or not.
>
> Currently, the easiest workaround is to rename .pyo to .pyc and all seems
> to work fine, even with a mixture of true .pyc and renamed .pyo files. (The
> same is true with the -O flag and no renaming.) This suggests that there is
> no current reason for the restriction in that the *execution* of bytecode
> is not affected by the -O flag. (Another workaround might be a custom
> importer -- but this is not trivial, apparently.)
>

In Python 3.3 it's actually trivial.


>
> So is the import restriction either an accident or obsolete holdover?


Neither. .pyo files are actually different from .pyc files in terms of what
bytecode they may emit. Currently -O causes all asserts to be left out of
the bytecode and -OO leaves out all docstrings on top of what -O does. This
makes a difference if you are trying to introspect at the interpreter
prompt or are testing things in development and want those asserts to be
triggered if needed.


> If so, can removing it be treated as a bugfix and put into current
> releases, or should it be treated as an enhancement only for a future
> release?
>
>
The behaviour shouldn't change. There has been talk of doing even more
aggressive optimizing under -O, which once again would cause an even larger
deviation between a .pyo file and a .pyc file (e.g. allowing Python code to
hook into the peephole optimizer or an entirely new AST optimizer).


> Or is the restriction an intentional reservation of the possibility of
> making *execution* depend on the flag? Which would mean that the
> restriction should be kept and only the doc changed?


The docs should get updated to be more clear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120613/003735bf/attachment.html>


More information about the Python-Dev mailing list