[Python-ideas] Disabling optimizations

[Ned Batchelder]

On 5/22/14 8:40 PM, Ethan Furman wrote:
> So, to hopefully summarize where we seem to have come to something of 
> a consensus:
>
>   - disabling optimizations can be a good thing
>
>   - creating a new command-line switch is an overpowered solution
>
>   - having a sys flag could work
>
>   - redefining the existing -O switch could work
>
>   - care must be taken to properly handle what is written to .pyc/.pyo 
> files
>
> Personally, I could live with either a sys flag type solution or the 
> -O solution, but I strongly favor the -O solution.
>
> Why?
>
> Partly because -O is for optimizations, so it naturally lends itself 
> to turning them off; partly because I think the current state of the 
> -O switches is sub-optimal (almost-pun intended ;); partly because I 
> see assert being used incorrectly and want to encourage the use of at 
> least -O; partly because running in __debug__ mode by default seems a 
> bit strange; and partly because running in __debug__ mode but having 
> optimizations turned on also seems a bit strange.
>
> I think the big question if we go this route is what gets written to 
> pyc files, and what to pyo files?

I'm of the opinion that we don't need to segregate bytecode into 
different files depending on the options used to create the bytecode.  
How often is the same program run in the same place with different 
options at different times?  I'm happy to have optimized and 
non-optimized code both written to .pyc files, and if you are fiddling 
with the options like that, you should delete your pyc files when you 
change the options.  If we come up with a way to have the bytecode 
file-segregated, I'm OK with that too.

I definitely don't like the alternative that says unoptimized code isn't 
written to disk at all.  If people want to solve the problem that way, 
there is already a mechanism to avoid writing bytecode, you can use it 
with the optimizer controls to achieve the effect you want.

--Ned.