Guido van Rossum schrieb: >On 11/11/05, Ulrich Berning <ulrich.berning at desys.de> wrote: > > >>For instance, nobody would give the output of a C compiler a different >>extension when different compiler flags are used. >> >> > >But the usage is completely different. With C you explicitly manage >when compilation happens. With Python you don't. When you first run >your program with -O but it crashes, and then you run it again without >-O to enable assertions, you would be very unhappy if the bytecode >cached in a .pyo file would be reused! > > > The other way round makes definitely more sense. At development time, I would never use Python with -O or -OO. I use it only at distribution time, after doing all the tests, to generate optimized bytecode. However, this problem could be easily solved, if the value of Py_OptimizeFlag would be stored together with the generated bytecode. At import time, the cached bytecode would not be reused if the current value of Py_OptimizeFlag doesn't match the stored value (if the .py file isn't there any longer, we could either raise an exception or we could emit a warning and reuse the bytecode anyway). And if we do this a little bit more clever, we could refuse reusing optimized bytecode if we are running without -O or -OO and ignore assertions and docstrings in unoptimized bytecode when we are running with -O or -OO. >>I would appreciate to see the generation of .pyo files completely >>removed in the next release. >> >> > >You seem to forget the realities of backwards compatibility. While >there are ways to cache bytecode without having multiple extensions, >we probably can't do that until Python 3.0. > > > Please can you explain what backwards compatibility means in this context? Generated bytecode is neither upwards nor backwards compatible. No matter what I try, I always get a 'Bad magic number' when I try to import bytecode generated with a different Python version. The most obvious software, that may depend on the existence of .pyo files are the various freeze/packaging tools like py2exe, py2app, cx_Freeze and Installer. I haven't checked them in detail, but after a short inspection, they seem to be independent of the existence of .pyo files. I can't imagine that there is any other Python software, that depends on the existence of .pyo files, but maybe I'm totally wrong in this wild guess. Ulli
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