> From: Guido van Rossum [mailto:guido@python.org] >=20 > > -OO removes asserts and docstrings. > >=20 > > I think this is an ideal time to revisit the purpose of -O=20 > for 2.4 or later. >=20 > Hm, I would think we can wait until after 2.3 is released, lest we be > tempted to "push one more feature into 2.3". I have absolutely *no* intention of pushing any of this for 2.3. Good = lord no. For a start, these would be major feature changes ... > > IMO the "vanilla" mode should be a "release" mode. Users should not > > have to use a command-line option to gain "release" optimisations > > such as asserts. >=20 > I strongly disagree, and I expect most Python users would. I think > this idea of a default harks back to the time when computers were slow > and you would put on your special debugging hat only when you had a > problem you couldn't solve by thinking about it. These days, often > you don't care about the small gain in speed that -O or even -OO > offers, because the program runs fast enough; but often you *do* care > about the extra checks that assert offers. (I know I do.) True. I'm ambivalent about that myself. But in that case, I would argue = instead that there should not be any option to remove asserts. > > .pyc and .pyo files would need to know which optimisations they were > > compiled with so that if they would be loaded again with the "wrong" > > optimisations they would be re-compiled. >=20 > That's what the difference between .pyc and .pyo was intended to > convey; IMO this was a mistake. Yep - I know this. I would actually suggest removing .pyo and simply = have the info held in the .pyc. > > Anyway, any thoughts, rebuttals, etc would be of interest. I'd like > > to get some discussion before I create a PEP. >=20 > I'm not convinced that we need anything, given the minimal effect of > most currently available optimizations. One of my options is to create a PEP specifically to have it rejected. However, I think there are definitely a couple of useful things in here. = In particular, it provides a path for introducing optimisations. One of = the complaints I have seen recently is that all optimisations are being = added to both paths. Perhaps this could be reduced to a process PEP with the following major = points: 1. Any new optimisation must be introduced on the optimised path. 2. Optimisations may be promoted from the optimised path to the vanilla = path at BDFL discretion. 3. Experimental optimisations in general will required at least one = complete release before being promoted from the optimised path to the = vanilla path. Tim Delaney
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