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