[Python-ideas] Changes to the existing optimization levels

[Nick Coghlan]

On 4 October 2017 at 01:42, Diana Clarke <diana.joan.clarke at gmail.com> wrote:
> On Sun, Oct 1, 2017 at 6:19 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Well, this is not really a bitfield, but a bitfield plus some irregular
>> hardcoded values.  Therefore I don't think it brings much in the way of
>> discoverability / understandability.
>>
>> That said, perhaps it makes implementation easier on the C side...
>
> I think I'm coming to the same conclusion: using bitwise operations
> for the optimization levels seems to just boil down to a more cryptic
> version of the simple "level 3" solution, with public-facing impacts
> to the pycache and existing interfaces etc that I don't think are
> worth it in this case.
>
> My only other thought at the moment, would be to use the existing -X
> option to achieve something similar to what I did with the new -N
> option, but then just quickly map that back to an integer under the
> hood. That is, "-X opt-nodebug -X opt-noassert" would just become
> "level 3" internally so that the various interfaces wouldn't have to
> change.

Sorry, I don't think I was entirely clear as to what my suggestion actually was:

* Switch to your suggested "set-of-strings" API at the Python level,
with the Python level integer interface retained only for backwards
compatibility
* Keep the current integer-based *C* optimization API, but redefine
the way that value is interpreted, rather than passing Python sets
around

The Python APIs would then convert the Python level sets to the
bitfield representation almost immediately for internal use, but you
wouldn't need to mess about with the bitfield yourself when calling
the Python APIs.

The difference I see relates to the fact that in Python:

* sets of strings are easier to work with than integer bitfields
* adding a new keyword-only argument to existing APIs is straightforward

While in C:

* integer bitfields are easier to work with than Python sets of Python strings
* supporting a new argument would mean defining a whole new parallel set of APIs

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia