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 -OO removes asserts and docstrings. I think this is an ideal time to revisit the purpose of -O for 2.4 or = later. 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 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. .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. Anyway, any thoughts, rebuttals, etc would be of interest. I'd like to = get some discussion before I create a PEP. Cheers. 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