On 11/6/06, Giovanni Bajo <rasky at develer.com> wrote: > > Martin v. Löwis wrote: > > >> Why not only import *.pyc files and no longer use *.pyo files. > >> > >> It is simpler to have one compiled python file extension. > >> PYC files can contain optimized python byte code and normal byte > >> code. > > > > So what would you do with the -O option of the interpreter? > > I just had an idea: we could have only pyc files, and *no* way to identify > whether specific "optimizations" (-O, -OO --only-strip-docstrings, > whatever) > were performed on them or not. So, if you regularly run different python > applications with different optimization settings, you'll end up with .pyc > files containing bytecode that was generated with mixed optimization > settings. It doesn't really matter in most cases, after all. I don't know about that. If you suspected that a failure could be because of some bytecode optimization you were trying wouldn't you like to be able to tell easily that fact? Granted our situation is not as bad as gcc in terms the impact of having to regenerate a compiled version, but it still would be nice to be able to make sure that every .pyc file is the same. We would need to make it easy to blast out every .pyc file found if we did allow mixing of optimizations (as you suggest below). Then, we add a single command line option (eg: "-I") which is: "ignore > *every* .pyc file out there, and regenerate them as needed". So, the few > times that you really care that a certain application is run with a > specific > setting, you can use "python -I -OO app.py". That might work. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20061106/dc398f8d/attachment.html
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