[Python-ideas] Changing optimisation level from a script

[MRAB]

On 2016-09-10 01:04, Damien George wrote:
>> What is to stop you from adding this to micropython as a library
>> extension?
>
> That's what I would like to do, and usually we do just go ahead and
> add our own extensions, trying to be Pythonic as possible :)
>
> But we do that a lot and sometimes I think it would be good to discuss
> with upstream (ie python-dev/python-ideas) about adding new
> functions/classes so that MicroPython doesn't diverge too much (eg
> Paul Sokolovsky had a discussion about time.sleep_ms, time.sleep_us
> etc, which was fruitful).  sys.optimize(value) is a pretty simple
> addition so I thought it would be a straight forward discussion to
> have here.
>
> I guess my main question to this list is: if CPython were to add a
> function to change the optimisation level at runtime, what would it
> look like?  I don't want to push CPython to actually add such a thing
> if it's not seen as a useful addition.  Instead I want to see how
> others would implement it if they needed to.
>
> A nice outcome would be that MicroPython adds the function now (eg
> sys.optimize), and in the future if CPython finds that it needs it, it
> also adds the same function with the same name/module/signature.
> Hence why I would like to add it correctly into MicroPython from the
> very beginning.
>
> Alternatively we can just use the micropython module and add
> micropython.optimize(value), and then if CPython does add it later on
> we'll have to change how we do it.
>
If I saw a function called 'optimize' which took an argument, I might 
initially think that it returns an optimised form of the argument, 
except that it's being called like a procedure, so it must be setting 
something.

Then there's the question of how to get the current optimisation level.

>> I've never felt the urge to do this and I don't think I've
>> ever heard it requested before. If you think it should be in the
>> stdlib, given the timing of the 3.6 feature freeze the earliest time
>> it could land would be Python 3.7.
>
> No, I definitely don't want to make a rush for 3.6.  I guess the
> timing of this post was not the best considering the 3.6 release :)
>
>> Finally, let's not define APIs with
>> British spelling. :-)
>
> Haha, the spelling never even crossed my mind!  Well, sys.opt() is
> definitely too short and confusing, so "optimize" would be the choice.
>
Perhaps:

sys.opt_level = 1