A quick update: after many months we are at the finish line. We are on
track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on
2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two
noteworthy regressions that have been identified and now fixed. Since
the issues for both
Chris Angelico wrote:
The wheel turns round and round, and the same spokes come up.
A discussion long past, and a discussion yet to come.
There are no beginnings or endings in the Wheel of Python...
--
Greg
___
Python-Dev mailing list
Python-Dev@py
Terry Reedy wrote:
How loop variables might be isolated without a nested scope: After a
comprehension is parsed, so that names become strings, rename the loop
variables to something otherwise illegal.
This doesn't change the situation conceptually, though, since
the question arises of why not
Ivan Pozdeev via Python-Dev wrote:
"as" was suggested even before is became a keyword in `with'. ( if
(re.match(regex,line) as m) is not None: )
That's not equivalent where/given, though, since it still
has the asymmetry problem.
--
Greg
___
Python-
On Mon, Jun 25, 2018 at 5:14 PM Steve Holden wrote:
> I'd like to ask: how many readers of
>
> this email have ever deliberately taken advantage of the limited Python 3
> scope in comprehensions and generator expressions to use what would
> otherwise be a conflicting local variable name?
>
I
On Mon, Jun 25, 2018 at 2:16 PM Steve Holden wrote:
> I'd like to ask: how many readers of
>
> this email have ever deliberately taken advantage of the limited Python 3
> scope in comprehensions and generator expressions to use what would
> otherwise be a conflicting local variable name?
>
On Mon, Jun 25, 2018 at 8:37 PM, Terry Reedy wrote:
> On 6/24/2018 7:25 PM, Guido van Rossum wrote:
>
>> I'd wager that the people who might be most horrified about it
>>
>
> the (b) scoping rule change
>
> would be people who feel strongly that the change to the
>> comprehension scope rules in P
On 6/25/2018 8:25 AM, Paul Moore wrote:
On 25 June 2018 at 12:44, Nick Coghlan wrote:
Unfortunately, I think the key rationale for (b) is that if you
*don't* do something along those lines, then there's a different
strange scoping discrepancy that arises between the non-comprehension
forms of c
On Tue, Jun 26, 2018 at 5:37 AM, Terry Reedy wrote:
> How loop variables might be isolated without a nested scope: After a
> comprehension is parsed, so that names become strings, rename the loop
> variables to something otherwise illegal. For instance, i could become
> '', just as lambda becomes
On 6/24/2018 7:25 PM, Guido van Rossum wrote:
I'd wager that the people who might be most horrified about it
the (b) scoping rule change
would be people who feel strongly that the change to the
comprehension scope rules in Python 3 is a big improvement,
I might not be one of those 'most hor
OK, last call! I'll accept the current draft tomorrow unless someone pushes
back.
On Fri, Jun 22, 2018 at 8:37 AM Nick Coghlan wrote:
> On 23 June 2018 at 01:16, Guido van Rossum wrote:
> > That sounds like you're supporting PEP 561 as is, right?
>
> Aye, I'm personally fine with it - we do nee
[This is my one reply in this thread today. I am trying to limit the amount
of time I spend to avoid another overheated escalation.]
On Mon, Jun 25, 2018 at 4:44 AM Nick Coghlan wrote:
> Right, the proposed blunt solution to "Should I use 'NAME = EXPR' or
> 'NAME := EXPR'?" bothers me a bit, but
Not giving a vote, as I'm just a lurker, but:
Le 25/06/2018 à 01:30, Greg Ewing a écrit :
>
> Actually, I'm closer to -1 on (a) as well. I don't like := as a
> way of getting assignment in an expression. The only thing I would
> give a non-negative rating is some form of "where" or "given".
This
On 25.06.2018 14:44, Nick Coghlan wrote:
On 25 June 2018 at 02:24, Guido van Rossum wrote:
A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for
inline assignment, (b) when := is used in a comprehension, set the scope for
the target as if the assignment occurred outside any c
On 25.06.2018 2:30, Greg Ewing wrote:
Guido van Rossum wrote:
Greg seem to be +0 or better for (a)
Actually, I'm closer to -1 on (a) as well. I don't like := as a
way of getting assignment in an expression. The only thing I would
give a non-negative rating is some form of "where" or "given".
On 25 June 2018 at 13:24, Nick Coghlan wrote:
> On 25 June 2018 at 22:17, Nick Coghlan wrote:
>> FWIW, the most cryptic parent local scoping related exception I've
>> been able to devise so far still exhibits PEP 572's desired "Omitting
>> the comprehension scope entirely would give you the same
On 25 June 2018 at 09:02, Guido van Rossum wrote:
> On Sun, Jun 24, 2018 at 11:50 AM Steven D'Aprano
> wrote:
>> I will have more to say about the whole "comprehensions are their own
>> scope" issue later. But I'd like to see Nick's proposed PEP, or at least
>> a draft of it, before making any fi
On 25 June 2018 at 22:17, Nick Coghlan wrote:
> FWIW, the most cryptic parent local scoping related exception I've
> been able to devise so far still exhibits PEP 572's desired "Omitting
> the comprehension scope entirely would give you the same name lookup
> behaviour" semantics:
>
> >>> def
On 25 June 2018 at 13:17, Nick Coghlan wrote:
> On 25 June 2018 at 09:25, Guido van Rossum wrote:
>> A "neutral" argument about (b) is that despite the "horrified" reactions
>> that Nick saw, in practice it's going to confuse very few people (again, due
>> to my point about Python's scope rules).
On 25 June 2018 at 12:44, Nick Coghlan wrote:
> Unfortunately, I think the key rationale for (b) is that if you
> *don't* do something along those lines, then there's a different
> strange scoping discrepancy that arises between the non-comprehension
> forms of container displays and the comprehen
On 25 June 2018 at 09:25, Guido van Rossum wrote:
> A "neutral" argument about (b) is that despite the "horrified" reactions
> that Nick saw, in practice it's going to confuse very few people (again, due
> to my point about Python's scope rules). I'd wager that the people who might
> be most horri
On 25 June 2018 at 02:24, Guido van Rossum wrote:
> A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for
> inline assignment, (b) when := is used in a comprehension, set the scope for
> the target as if the assignment occurred outside any comprehensions. It
> seems we have more
Thanks, Jeroen.
I haven't review your code yet, but benchmark shows no significant
slowdown. It's good start!
$ ./python -m perf compare_to master.json pep580.json -G --min-speed=5
Slower (6):
- scimark_fft: 398 ms +- 20 ms -> 442 ms +- 42 ms: 1.11x slower (+11%)
- xml_etree_process: 99.6 ms +-
23 matches
Mail list logo
