Re: [Python-ideas] Changing optimisation level from a script
Thanks all for the input on this topic. Let me summarise what was said. There was discussion that the ability to change the "optimize" value is not enough and there should be more fine grained control over other flags/settings. Perhaps that is true, but at least for our case in MicroPython there's only one (runtime) optimisation variable and it mimics CPython's -O command line option (affecting __debug__, assert compilation, and whether line numbers are included in the bytecode). Suggestions for setting the opt level were: 1) sys.set_default_optimize(level), with the existing sys.flags.optimize attribute as the accessor. 2) sys.opt_level, being a read/write attribute 3) sys._setflag(name, value) as implemented by eGenix PyRun I think option 1 is the most consistent with the existing sys module, although the name is rather long and I think sys.set_optimize(level) would be better (after all, none of the other sys.set functions have the word default in them). As a second preference I like micropython.opt_level([value]), which can set and get the value, and keeps it specific to uPy. Cheers, Damien.
On 13 September 2016 at 17:34, Damien George <damien.p.george@gmail.com> wrote:
For CPython, where we have quite a few different runtime settings, something like the general purpose eGenix interface probably makes more sense, for the same reason we added sys.flags in the first place: reducing the level of API sprawl in the sys module.
As a second preference I like micropython.opt_level([value]), which can set and get the value, and keeps it specific to uPy.
And if you went that way, any future general purpose "runtime flag manipulation" API could just provide a then wrapper around that for the optimisation flag, while still exposing this API for use from MicroPython-specific boostrapping files. Given those two points, I think "micropython.opt_level([value])" would be the right way to go, with the official stance for CPython being that configuration is an environmental problem, but some environments (like PyRun and MicroPython) will expose a Python API rather than using an external mechanism. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 13 September 2016 at 17:34, Damien George <damien.p.george@gmail.com> wrote:
For CPython, where we have quite a few different runtime settings, something like the general purpose eGenix interface probably makes more sense, for the same reason we added sys.flags in the first place: reducing the level of API sprawl in the sys module.
As a second preference I like micropython.opt_level([value]), which can set and get the value, and keeps it specific to uPy.
And if you went that way, any future general purpose "runtime flag manipulation" API could just provide a then wrapper around that for the optimisation flag, while still exposing this API for use from MicroPython-specific boostrapping files. Given those two points, I think "micropython.opt_level([value])" would be the right way to go, with the official stance for CPython being that configuration is an environmental problem, but some environments (like PyRun and MicroPython) will expose a Python API rather than using an external mechanism. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
Damien George -
Nick Coghlan