Alexandre Zani wrote:
On Tue, Jun 12, 2012 at 11:41 AM, Ethan Furman <et...@stoneleaf.us> wrote:
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.
What if I change .py?
Well, the case in question is that there is no .py available.
But if it were available, and you changed it, then it would and should
work just like it does now -- if .py is newer, compile it; if -O was
specified, compile it optimized; now run the compiled code.
~Ethan~
_______________________________________________
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
