Brett Cannon wrote: > On Tue, Jun 12, 2012 at 2:16 PM, Terry Reedy 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. But what does this have to do with those cases where *only* the .pyo file is available, and we are trying to run it? In these cases it would have to be in the main folder (not __pycache__) which means somebody did it deliberately. ~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4