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.
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. Cheers, Damien.