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

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

2017-10-03 Thread Nick Coghlan
On 4 October 2017 at 01:42, Diana Clarke wrote: > 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

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

2017-10-03 Thread Antoine Pitrou
On Tue, 3 Oct 2017 09:42:40 -0600 Diana Clarke wrote: > - mixed-bag -X options are less discoverable than just adding a > new command line option (like -N or -OOO) For such a feature, I think being less discoverable is not really a problem. I don't think many

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

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

2017-10-02 Thread Nick Coghlan
On 1 October 2017 at 22:19, Antoine Pitrou wrote: >> 2. We could reinterpret "optimize" as a bitfield instead of a regular >> integer, special casing the already defined values: >> >> - all zero: no optimizations >> - sign bit set: negative -> use global settings >> - 0x0001:

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

2017-10-01 Thread Antoine Pitrou
On Fri, 29 Sep 2017 17:33:11 +1000 Nick Coghlan wrote: > > That said, we may also want to consider a couple of other options > related to changing the meaning of *existing* parameters to these > APIs: > > 1. We have the PyCompilerFlags struct that's currently only used to >

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

2017-09-30 Thread Terry Reedy
On 9/30/2017 4:36 PM, Diana Clarke wrote: In the mean time, I've re-opened the following pull request that can be merged independent of these changes (it's just additional test coverage). trivial: add test coverage for the __debug__ case (optimization levels)

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

2017-09-30 Thread Diana Clarke
In the mean time, I've re-opened the following pull request that can be merged independent of these changes (it's just additional test coverage). trivial: add test coverage for the __debug__ case (optimization levels) https://github.com/python/cpython/pull/3450 Please let me know if I

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

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

2017-09-29 Thread Ned Batchelder
On 9/28/17 2:48 PM, Diana Clarke wrote: 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

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

2017-09-29 Thread Nick Coghlan
On 29 September 2017 at 05:02, Antoine Pitrou wrote: > On Thu, 28 Sep 2017 12:48:15 -0600 > Diana Clarke > wrote: >> >> 2) Added a new command line option N that allows you to specify >> any number of individual optimization flags. >> >>

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

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

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

2017-09-28 Thread Victor Stinner
> 2) Added a new command line option N that allows you to specify > any number of individual optimization flags. > > For example: > > python -N nodebug -N noassert -N nodocstring You may want to look at my PEP 511 which proposes to add a new "-o" option to specify a list of

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

2017-09-28 Thread Antoine Pitrou
On Thu, 28 Sep 2017 12:48:15 -0600 Diana Clarke wrote: > > 2) Added a new command line option N that allows you to specify > any number of individual optimization flags. > > For example: > > python -N nodebug -N noassert -N nodocstring We could