[Python-Dev] Thoughts on -O

[Delaney, Timothy C (Timothy)]

> 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