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

Kristján Valur Jónsson kristjan at ccpgames.com
Wed Jun 13 00:03:30 CEST 2012

[Vaguely related: -B prevents the writing of .pyc and .pyo (don't know how it works for pep 3147) However, it doesn't prevent the reading of said files. It's been discussed here before and considered useful, since rudiment .pyc files tend to stick around. Maybe a -BB flag should be considered?] K

Frá: python-dev-bounces+kristjan=ccpgames.com at python.org [python-dev-bounces+kristjan=ccpgames.com at python.org] fyrir hönd Ronan Lamy [ronan.lamy at gmail.com] Sent: 12. júní 2012 19:57 To: Ethan Furman Cc: python-dev at python.org Efni: Re: [Python-Dev] #12982: Should -O be required to read .pyo files?

Le mardi 12 juin 2012 à 11:41 -0700, Ethan Furman a écrit :

Terry Reedy wrote: > 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.) > > So is the import restriction either an accident or obsolete holdover? 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? > > 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?

I have no history so cannot say what was supposed to happen, but my $0.02 would be that if -O is not specified then we should try to read .pyc, then .pyo, and finally .py. In other words, I vote for -O being a write flag, not a read flag.

I don't know much about the history either, but under PEP 3147, there are really two cases:

In the first case, I think that -O should dictate which of .pyc and .pyo is used, while the other is completely ignored.

In the second case, both .pyc and .pyo should always be considered as valid module sources, because -O is a compilation flag and loading a bytecode file doesn't involve compilation. At most, -O could switch the priority between .pyc and .pyo.

2.7 doesn't really differentiate between cached .pyc and standalone .pyc, so I don't know if a consistent behaviour can be achieved. Maybe the presence or absence of a matching .py can be used to trigger the first or second case above.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com

More information about the Python-Dev mailing list