[Python-Dev] Thoughts on -O (original) (raw)

Delaney, Timothy C (Timothy) tdelaney@avaya.com
Tue, 29 Apr 2003 10:59:41 +1000

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