On Thu, May 22, 2014 at 11:59 AM, Steven D'Aprano
On Thu, May 22, 2014 at 03:41:31PM +0000, Steve Dower wrote:
Why not move the existing optimisation into -O mode and put future optimisations in there too? It may just start having enough value that people switch to using it.
I just had the same idea, you beat me to it.
Same here. More concretely: -O0 -- no optmizations at all -O1 -- level 1 optimizations (current peephole optmizations), asserts disabled -O2 -- level 2 optimizations (currently nothing extra) -O3 -- ... -ONs or -X nodocstrings or -X compact or --compact or --nodocstrings -- remove docstrings (for space savings) --debug or -X debug -- sets __debug__ to True (also implies -O0) Compatibility (keeping the current behavior): Default: -O<max> + __debug__ = True (deprecate setting __debug__ to True?) -O -- same as -O<max> -OO -- same as -O<max>s (deprecate) Having the current optimizations correspond to -O1 makes sense in that we don't have anything more granular. However, if more optimizations were added I'd expect them to fall under a higher optimization level. Adding a new option just for docstrings/compact seems like a I waste so I like Stefan's idea of optionally appending "s" (for space) onto the -O option. As Barry noted, we would also build on PEPs 3147/3149 to add a tag for the optmization level, etc. The default mode would keep the current cache tag and -O/-OO would likewise stay the same (with the .pyo suffix).
* The double -OO switch should be deprecated, for eventual removal in the very distant future. (4.0? 5.0?)
Good idea.
* Instead, a separate switch for removing docstrings can be added, to support implementations in low-memory devices or other constrained situations.
Also a good idea.
This will make Python's compilation model a little more familiar to people coming from other languages. It will make -O more attractive, instead of being viewed by some as a waste of effort, and ensure that by default there are no tricks played with byte-code.
+1 -eric