Re: [Python-ideas] Changes to the existing optimization levels

2017-10-05 Thread Diana Clarke
Thanks, Nick! I'll let this sink in today and give it a shot tomorrow. Have a great weekend, --diana > * 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

Re: [Python-ideas] Changes to the existing optimization levels

2017-10-03 Thread Diana Clarke
On Sun, Oct 1, 2017 at 6:19 AM, Antoine Pitrou 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

Re: [Python-ideas] Changes to the existing optimization levels

2017-09-30 Thread Diana Clarke
know if I should create a bpo for it, if the commit message is too long, or if you think I should otherwise change the patch in any way. As always, thanks for your time folks! --diana On Fri, Sep 29, 2017 at 2:24 PM, Diana Clarke wrote: > Oh, I like this idea! > > I had very briefly cons

Re: [Python-ideas] Changes to the existing optimization levels

2017-09-29 Thread Diana Clarke
Oh, I like this idea! I had very briefly considered treating the existing flag as a bitfield, but then promptly forgot to explore that line of thought further. I'll play with that approach next week, see where it takes me, and then report back. Thanks so much for taking the time to think this th

Re: [Python-ideas] Changes to the existing optimization levels

2017-09-29 Thread Diana Clarke
I suppose anything is possible ;) Perhaps I'll try my hand at that next. But no, I'm limiting the scope to the existing toggles only (docstrings, __debug__, assert) for this pass. I am aware of that thread though. I read it a few weeks back when I was initially researching the existing implementa

Re: [Python-ideas] Changes to the existing optimization levels

2017-09-28 Thread Diana Clarke
Perhaps I should be a bit clearer. When I said the "level 3" approach "appears to be inline with the direction Victor Stinner is going in for PEP 511", it was mostly at a superficial level. Meaning: - PEP 511 still appears to use integer (unnamed) optimization levels for alternate transformers (f

Re: [Python-ideas] Changes to the existing optimization levels

2017-09-28 Thread Diana Clarke
Yup. I referenced your pep a few times in a previous off-list email, but I omitted that paragraph from this pass because I was using it to bolster the previous "level 3" idea (which didn't fly). """ This simple approach to new optimization levels also appears to be inline with the direction Victor

[Python-ideas] Changes to the existing optimization levels

2017-09-28 Thread Diana Clarke
Hi folks: I was recently looking for an entry-level cpython task to work on in my spare time and plucked this off of someone's TODO list. "Make optimizations more fine-grained than just -O and -OO" There are currently three supported optimization levels (0, 1, and 2). Briefly summarized, the