Was doing some thinking in the shower this morning, and came up with some ideas for specifying optimisation. These are currently quite nebulous thoughts ...

We have the current situation:

-O only removes asserts

It may do some more, but not much more now that SET_LINENO is never generated.

-OO removes asserts and docstrings.

I think this is an ideal time to revisit the purpose of -O for 2.4 or later.

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".

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.

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.)

I would propose that we have the following modes for python to work in.

1. Release/Production mode (no command-line switch)

- asserts are turned off - well-tested/stable optimisations are included - possibly additional things, such as not calling trace functions

2. Optimised mode (-O)

- more experimental optimisations are included i.e. those that may have performance improvements in some cases, but penalties in others, etc

- may possibly split this up so individual optimisations can be turned on and off as required - this would leave -O by itself as a no-op

3. Docstring elimination mode (-OO)

- may be specified in addition to optimised mode - it does not imply optimised mode

4. Debug mode (-D?)

- will be the slowest mode - no optimisations - cannot be called with either -O or -OO - turns on asserts - turns on trace functions

I would see Debug mode being used by developers in unit tests, code coverage, etc.

If I'm right about how Python is used, most Python users are in debug mode most of the time. So this ought to be the default.

.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.

That's what the difference between .pyc and .pyo was intended to convey; IMO this was a mistake.

Anyway, any thoughts, rebuttals, etc would be of interest. I'd like to get some discussion before I create a PEP.

I'm not convinced that we need anything, given the minimal effect of most currently available optimizations. --Guido van Rossum (home page: http://www.python.org/~guido/)

Was doing some thinking in the shower this morning, and came up with some ideas for specifying optimisation. These are currently quite nebulous thoughts ...

We have the current situation:

-O only removes asserts

It may do some more, but not much more now that SET_LINENO is never generated.

-OO removes asserts and docstrings.

I think this is an ideal time to revisit the purpose of -O for 2.4 or later.

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".

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.

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.)

I would propose that we have the following modes for python to work in.

1. Release/Production mode (no command-line switch)

- asserts are turned off - well-tested/stable optimisations are included - possibly additional things, such as not calling trace functions

2. Optimised mode (-O)

- more experimental optimisations are included i.e. those that may have performance improvements in some cases, but penalties in others, etc

- may possibly split this up so individual optimisations can be turned on and off as required - this would leave -O by itself as a no-op

3. Docstring elimination mode (-OO)

- may be specified in addition to optimised mode - it does not imply optimised mode

4. Debug mode (-D?)

- will be the slowest mode - no optimisations - cannot be called with either -O or -OO - turns on asserts - turns on trace functions

I would see Debug mode being used by developers in unit tests, code coverage, etc.

If I'm right about how Python is used, most Python users are in debug mode most of the time. So this ought to be the default.

.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.

That's what the difference between .pyc and .pyo was intended to convey; IMO this was a mistake.

Anyway, any thoughts, rebuttals, etc would be of interest. I'd like to get some discussion before I create a PEP.

I'm not convinced that we need anything, given the minimal effect of most currently available optimizations. --Guido van Rossum (home page: http://www.python.org/~guido/)