Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jul 3, 2018 at 4:25 PM Victor Stinner wrote: > 2018-07-02 20:19 GMT+02:00 Guido van Rossum : > > Thank you all. I will accept the PEP as is. (...) > > I see more and more articles ("on the Internet") saying that Guido van > Rossum already accepted the PEP. Is the PEP already accepted or

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

2018-07-02 20:19 GMT+02:00 Guido van Rossum : > Thank you all. I will accept the PEP as is. (...) I see more and more articles ("on the Internet") saying that Guido van Rossum already accepted the PEP. Is the PEP already accepted or will be accepted? Right now,

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Terry Reedy wrote: If we had followed the math precedent, instead of language>, we would have set builders, list builders, dict builders, and generator builders. I was intending to suggest something like that back when comprehensions were first being discussed, but people raced ahead and

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

I smell a new thread. :-) On Tue, Jul 3, 2018 at 3:06 PM Terry Reedy wrote: > On 7/3/2018 2:42 AM, Tim Peters wrote: > > > So if we had it to do over again I'd sigh and accept "generator > > comprehensions" anyway. It's been an eternal PITA - and especially in > > the PEP 572 threads! - to

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 7/3/2018 2:42 AM, Tim Peters wrote: So if we had it to do over again I'd sigh and accept "generator comprehensions" anyway.  It's been an eternal PITA - and especially in the PEP 572 threads! - to keep typing "comprehensions or generator expressions".  Then again, if I had the power of

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, Jul 2, 2018 at 11:42 PM, Tim Peters wrote: > "comprehensions" was always a dubious term, carried over from set theory > where the term focuses on the optional "if" part rather than the more > fundamental iterator or computation parts. > I always wondered about that :-) -- I'd say for

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 03/07/2018 06:47, Tim Peters wrote: [Rob Cliffe] > It's late to raise this, By months, yes ;-) > but what exactly are the objections to the syntax >         expr -> name  # or variations such as  expr => name > instead of >         name := expr > > The PEP mentions that this syntax does

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker] > > However, generator expressions ( why don’t we call them generator > > comprehensions?) Because nobody really liked the "iterator comprehensions" or "accumulator displays" they were variously called at the start.

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Rob Cliffe] > It's late to raise this, By months, yes ;-) > but what exactly are the objections to the syntax > > expr -> name # or variations such as expr => name > > instead of > > name := expr > > > > The PEP mentions that this syntax does not have a problem that "as"

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

> On Jul 2, 2018, at 8:34 AM, Steven D'Aprano wrote: Guido has decided — and despite my concerns, I’m going to enjoy my new loop-and-a half construct:-) But a comment on this: > comprehension are no more special than > assignments inside any other expression. They bind in the current scope, >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 02/07/2018 19:19, Guido van Rossum wrote: Thank you all. I will accept the PEP as is. I am happy to accept *clarification* updates to the PEP if people care to submit them as PRs to the peps repo (https://github.com/python/peps), and that could even (to some extent) include summaries of

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Michael Selik] >>> My worry is that assignment expressions will add about 15 to 20 >>> minutes to my class and a slight discomfort. [Tim] >> So not intractable - which is my high-order bit ;-) >> >> For those who want more bits of precision (perhaps Guido), while >> quantification is good, it

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Thank you all. I will accept the PEP as is. I am happy to accept *clarification* updates to the PEP if people care to submit them as PRs to the peps repo (https://github.com/python/peps), and that could even (to some extent) include summaries of discussion we've had, or outright rejected ideas.

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 07:29:52PM -0500, Tim Peters wrote: [...] > For example, if the name is declared "global" in the outer scope, you'll > get a compile-time error if you try to declare it "nonlocal" in the > contained scope. "parentlocal" adjusts its meaning accordingly, becoming a > synonym

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 03:31:42PM -0700, Guido van Rossum wrote: > I'd also like to keep the rule prohibiting use of the same name as a > comprehension loop control variable and as an inline assignment target; > this rule would also prohibit shenanigans with nested comprehensions (for > any set

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, Jul 2, 2018 at 2:34 AM Michael Selik wrote: > > On Sun, Jul 1, 2018 at 8:21 PM Matt Arcidy wrote: >> >> [...] Can anyone adequately explain why this specific modality of learning, >> a student-in-a-seat based educator, must outweigh all other modalities [...]? > > > 1. It doesn't. > 2.

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 8:21 PM Matt Arcidy wrote: > [...] Can anyone adequately explain why this specific modality of > learning, a student-in-a-seat based educator, must outweigh all other > modalities [...]? 1. It doesn't. 2. It's a proxy for the other modes. I hope this was an adequate

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 11:36 PM Tim Peters wrote: > [Michael Selik] > > My worry is that assignment expressions will add about 15 to 20 > > minutes to my class and a slight discomfort. > > So not intractable - which is my high-order bit ;-) > > For those who want more bits of precision (perhaps

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, 2 Jul 2018 10:25:42 +1000 Steven D'Aprano wrote: > > How do people who teach other languages deal with this? > > Assignment expressions are hardly a new-fangled innovation of Python's. > They're used in Java, Javascript, Ruby, Julia, R, PHP and of course > pretty much the entire C

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Is this message some kind of joke or did you just send it to the wrong mailing-list/recipient? On Sun, 1 Jul 2018 20:21:19 -0700 Matt Arcidy wrote: > This cynical view on students is shocking! Everyone on this list has > been a student or a learner for far longer than an educator, and the >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Tim] >> ... >> So, ya, when someone claims [assignment expressions will] make >> Python significantly harder to teach, I'm skeptical of that claim. [Michael Selik] > I don't believe anyone is making that claim. I haven't seen it in this specific thread, but the larger discussion has been going

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 5:25 PM, Steven D'Aprano wrote: > > > an optional topic. Once widely used, it ain't optional. > > Without knowing the details of your course, and who they are aimed at, > we cannot possibly judge this comment. Decorators are widely used, but > surely you don't teach them

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

This cynical view on students is shocking! Everyone on this list has been a student or a learner for far longer than an educator, and the perspective from students and learners are far more important than educators to assess this angle regardless. Can anyone adequately explain why this specific

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 5:28 PM Steven D'Aprano wrote: > On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote: > > On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > > > > > So, ya, when someone claims [assignment expressions will] make Python > > > significantly harder to teach, I'm

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote: > On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > > > So, ya, when someone claims [assignment expressions will] make Python > > significantly harder to teach, I'm skeptical of that claim. > > > > I don't believe anyone is making

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 8:35 AM, Michael Selik wrote: > As Mark and Chris said (quoting Mark below), this is just one straw in the > struggle against piling too many things on the haystack. Unlike some > changes to the language, this change of such general use that it won't be > an optional

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > So, ya, when someone claims [assignment expressions will] make Python > significantly harder to teach, I'm skeptical of that claim. > I don't believe anyone is making that claim. My worry is that assignment expressions will add about 15 to 20

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 7:28 PM, Chris Barker via Python-Dev < python-dev@python.org> wrote: > > But once it becomes a more common idiom, students will see it in the wild > pretty early in their path to learning python. So we'll need to start > introducing it earlier than later. > > I think this

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

I think I'll bow out of this now. It's just too tedious. Like here: [Nick] > I never said the motivation was to gain performance relative to the > two-statement version - I said the motivation given in the PEP is to > gain performance relative to the *repeated subexpression* version, >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 11:32:03PM -0500, Tim Peters wrote: [...] > So, no, gaining performance is _not_ the motivation here. You already had > a way to make it "run fast'. The motivation is the _brevity_ assignment > expressions allow while _retaining_ all of the two-statement form's >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 1 July 2018 at 14:32, Tim Peters wrote: > [Nick] > >> The PEP specifically cites this example as motivation: > > The PEP gives many examples. Your original was a strawman > mischaracterization of the PEP's _motivations_ (note the plural: you only > mentioned "minor performance improvement",

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Nick Coghlan wrote: That's a performance argument, not a readability one (as if you don't care about performance, you can just repeat the subexpression). Repeated subexpressions can be a readability issue too, since you have to examine them to notice they are actually the same. They also

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Nick Coghlan] >>> "NAME := EXPR" exists on a different level of complexity, since it >>> adds name binding in arbitrary expressions for the sake of minor >>> performance improvement in code written by developers that are >>> exceptionally averse to the use of vertical screen real estate, > >>>

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 1 July 2018 at 02:37, Tim Peters wrote: > [Nick Coghlan] > >> ... > >> "NAME := EXPR" exists on a different level of complexity, since it > >> adds name binding in arbitrary expressions for the sake of minor > >> performance improvement in code written by developers that are > >> exceptionally

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/30/2018 5:35 AM, Steven D'Aprano wrote: I've given reasons why I believe that people will expect assignments in comprehensions to occur in the local scope. Aside from the special case of loop variables, people don't think of comprehensions as a separate scope. I think this is because

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 9:43 AM Tim Peters wrote: > The attractions are instead in the areas of reducing redundancy, improving > clarity, allowing to remove semantically pointless indentation levels in > some cases, indeed trading away some horizontal whitespace in otherwise > nearly empty lines

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Nick Coghlan] > > ... > > "NAME := EXPR" exists on a different level of complexity, since it > > adds name binding in arbitrary expressions for the sake of minor > > performance improvement in code written by developers that are > > exceptionally averse to the use of vertical screen real

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 30 June 2018 at 19:35, Steven D'Aprano wrote: > So I think Q1 is the critical one. And I think the answer is, no, > they're conceptually bloody simple. They evaluate the expression on the > right, assign it to the name on the left, and return that value. And the proposed parent local scoping

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 03:42:49PM -0700, Chris Barker via Python-Dev wrote: > If we think hardly anyone is ever going to do that -- then I guess it > doesn't matter how it's handled. That's how you get a language with surprising special cases, gotchas and landmines in its behaviour. (Cough PHP

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 06:30:56PM +1000, Nick Coghlan wrote: > The significant semantic differences between "{x : 1}" and "{x := 1}" > are also rather surprising :) *Significant* and obvious differences are good. It's the subtle differences that you don't notice immediately that really hurt:

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 30 June 2018 at 09:49, Chris Barker - NOAA Federal via Python-Dev wrote: >> On Jun 28, 2018, at 8:21 PM, Tim Peters wrote: > > Seems it’s all been said, and Tim’s latest response made an excellent > case for consistency. > > But: > >> Regardless of how assignment expressions work in listcomps

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 29 June 2018 at 08:42, Chris Barker via Python-Dev wrote: > On Thu, Jun 28, 2018 at 9:28 AM, Tim Peters wrote: >> Did adding ternary `if` (truepart if expression else falsepart) complicate >> the language significantly? > > > I don't think so -- no. For two reasons: > > 1) the final chosen

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 09:52:43PM -0700, Chris Barker wrote: > It seems everyone agrees that scoping rules should be the same for > generator expressions and comprehensions, Yes. I dislike saying "comprehensions and generator expressions" over and over again, so I just say "comprehensions".

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 28 June 2018 at 08:31, Guido van Rossum wrote: > So IIUC you are okay with the behavior described by the PEP but you want an > explicit language feature to specify it? > > I don't particularly like adding a `parentlocal` statement to the language, > because I don't think it'll be generally

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Tim] >> Regardless of how assignment expressions work in listcomps and genexps, >> this example (which uses neither) _will_ rebind the containing block's `x`: > >> > >> [x := 1] > [Chris Barker] > This reinforces my point that it’s not just about comprehensions, I agree, it's not at all - and

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

> On Jun 28, 2018, at 8:21 PM, Tim Peters wrote: Seems it’s all been said, and Tim’s latest response made an excellent case for consistency. But: > Regardless of how assignment expressions work in listcomps and genexps, this > example (which uses neither) _will_ rebind the containing block's

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/28/2018 11:21 PM, Tim Peters wrote: [somewhere below] this is the last time I'm going to repeat it all again ;-) For me, this is your most convincing exposition and summary of why the proposal is at least ok. Thank you. [Chris] > yes, it was a contrived example, but the simplest one

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris] > yes, it was a contrived example, but the simplest one I could think of off > the top of my head that re-bound a name in the loop -- which was what I > thought was the entire point of this discussion? But why off the top of your head? There are literally hundreds & hundreds of prior

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Baptiste Carvello wrote: x=0; [x:=x+i for i in range(5)] what would be a non-cryptic alternative to the above example? Personally I wouldn't insist on trying to do it with a comprehension at all, but if forced to come up with a readable syntax for that, it would probably be something like

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 9:28 AM, Tim Peters wrote: > >>> g = (x:=i for i in range(3)) > Common or not, I have no idea why anyone would write a genexp like the one > you gave, except to contrive an example of silly behavior exhibited by > silly code ;-) > yes, it was a contrived example, but the

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/28/2018 8:05 AM, Baptiste Carvello wrote: Le 28/06/2018 à 01:31, Greg Ewing a écrit : Well, I remain profoundly unconvinced that writing comprehensions with side effects is ever a good idea, and Tim's examples did nothing to change that. Comprehensions with side effects feel scary

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker] >>> So what about: >>> >>> l = [x:=i for i in range(3)] >>> >>> vs >>> >>> g = (x:=i for i in range(3)) >>> >>> Is there any way to keep these consistent if the "x" is in the regular local scope? [Tim] >> I'm not clear on what the question is. The list comprehension would >> bind

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Sent from my iPhone > > So what about: > > > > l = [x:=i for i in range(3)] > > > > vs > > > > g = (x:=i for i in range(3)) > > > > Is there any way to keep these consistent if the "x" is in the regular > > local scope? > > I'm not clear on what the question is. The list comprehension would

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Le 28/06/2018 à 01:31, Greg Ewing a écrit : > Well, I remain profoundly unconvinced that writing comprehensions > with side effects is ever a good idea, and Tim's examples did > nothing to change that. Comprehensions with side effects feel scary indeed. But I could see myself using some variant

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

✨ Congrats Nick on your 100 emails thread ! ✨ You won a virtual piece of cake:  2018-06-22 16:22 GMT+02:00 Nick Coghlan : > On 22 June 2018 at 02:26, Antoine Pitrou wrote: >> Indeed. But, for a syntax addition such as PEP 572, I think it would be >> a good idea to ask their opinion to

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker] > ... > So what about: > > l = [x:=i for i in range(3)] > > vs > > g = (x:=i for i in range(3)) > > Is there any way to keep these consistent if the "x" is in the regular local scope? I'm not clear on what the question is. The list comprehension would bind ` l ` to [0, 1, 2] and

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 12:01 PM, Eric V. Smith wrote: > >>> def test(): > >>>spam = 1 > >>>ham = 2 > >>>vars = [key1+key2 for key1 in locals() for key2 in locals()] > >>>return vars > >>> > >>> Wanna guess what that's gonna return? > Guessing aside, messing around with locals()

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Guido] > .. > Given that definition of `__parentlocal`, in first approximation the > scoping rule proposed by PEP 572 would then be: In comprehensions > (which in my use in the PEP 572 discussion includes generator > expressions) the targets of inline assignments are automatically > endowed with

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 11:29 AM, Ivan Pozdeev via Python-Dev wrote: > On 28.06.2018 2:44, Greg Ewing wrote: >> >> Ivan Pozdeev via Python-Dev wrote: >>> >>> for me, the primary use case for an assignment expression is to be able >>> to "catch" a value into a variable in places where I can't put

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 28.06.2018 2:44, Greg Ewing wrote: Ivan Pozdeev via Python-Dev wrote: for me, the primary use case for an assignment expression is to be able to "catch" a value into a variable in places where I can't put an assignment statement in, like the infamous `if re.match() is not None'. This

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Tim] > If the parent has a matching parentlocal declaration for the same > name then the original > > really refers to the grandparent - and so on. > [Greg] > Ah, I missed that part, sorry -- I withdraw that particular > objecttion. > Good! I have another reply that crossed in the mail.

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Ivan Pozdeev via Python-Dev wrote: for me, the primary use case for an assignment expression is to be able to "catch" a value into a variable in places where I can't put an assignment statement in, like the infamous `if re.match() is not None'. This seems to be one of only about two uses for

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

> [Nick Coghlan] > I'm OK with a target scope declaration construct having > > lexical-scope-dependent behaviour - exactly what "nonlocal NAME" will > > do depends on both the nature of the current scope, > [Greg Ewing] > Yes, but my point is that having an explicit "parentlocal" scope >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Tim Peters wrote: If the parent has a matching parentlocal declaration for the same name then the original really refers to the grandparent - and so on. Ah, I missed that part, sorry -- I withdraw that particular objecttion. Still, this seems like a major addition (seeing as it comes with a

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 28.06.2018 2:31, Greg Ewing wrote: Steven D'Aprano wrote: The *very first* motivating example for this proposal came from a comprehension. I think it is both unfortunate and inevitable that the discussion bogged down in comprehension-hell. I think the unfortunateness started when we

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Ivan Pozdeev via Python-Dev wrote: This isn't as messy as you make it sound if you remember that the outermost iterable is evaluated only once at the start and all the others -- each iteration. Anyone using comprehensions has to know this fact. That fact alone doesn't imply anthing about the

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 28.06.2018 2:45, Ivan Pozdeev via Python-Dev wrote: On 28.06.2018 2:31, Ivan Pozdeev via Python-Dev wrote: On 28.06.2018 1:42, Steven D'Aprano wrote: On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via Python-Dev wrote: What this means in practice is that assignments will go to

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Nick Coghlan wrote: I'm OK with a target scope declaration construct having lexical-scope-dependent behaviour - exactly what "nonlocal NAME" will do depends on both the nature of the current scope, Yes, but my point is that having an explicit "parentlocal" scope declaration doesn't help to

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 28.06.2018 2:31, Ivan Pozdeev via Python-Dev wrote: On 28.06.2018 1:42, Steven D'Aprano wrote: On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via Python-Dev wrote: What this means in practice is that assignments will go to different scopes depending on *where* they are in the

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 28.06.2018 1:42, Steven D'Aprano wrote: On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via Python-Dev wrote: What this means in practice is that assignments will go to different scopes depending on *where* they are in the comprehension: [ expr for x in iter1 for y in iter2

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Steven D'Aprano wrote: The *very first* motivating example for this proposal came from a comprehension. I think it is both unfortunate and inevitable that the discussion bogged down in comprehension-hell. I think the unfortunateness started when we crossed over from talking about binding a

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 9:27 AM Paul Moore wrote: > From my reading, PEP 572 takes the position that "parent local > scoping" is what people expect from assignment expressions *in > comprehensions* and it's useful enough that there is no reason not to > make that the behaviour. The behaviour

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via Python-Dev wrote: > >What this means in practice is that assignments will go to different > >scopes depending on *where* they are in the comprehension: > > > > [ expr for x in iter1 for y in iter2 if cond ...] > > [ BB

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

So IIUC you are okay with the behavior described by the PEP but you want an explicit language feature to specify it? I don't particularly like adding a `parentlocal` statement to the language, because I don't think it'll be generally useful. (We don't have `goto` in the language even though it

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

> On Jun 27, 2018, at 9:49 AM, Steven D'Aprano wrote: > >> On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote: >>> On 6/27/2018 7:08 AM, Chris Angelico wrote: >>> It gets funnier with nested loops. Or scarier. I've lost the ability >>> to distinguish those two. >>> >>> def test():

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Nick Coghlan] > However, PEP 572 in its current form takes the position "parent local > scoping is sufficiently useful to make it a required pre-requisite for > adding assignment expressions, but not useful enough to expose as a > new scope declaration primitive", > Of course the PEP doesn't

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Nick Coghlan]> > actually made those semantics available as an explicit > "parentlocal NAME" declaration ...: > > > > def _list_comp(_outermost_iter): > > parentlocal item > > _result = [] > > for x in _outermost_iter: > > item = x > >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27 June 2018 at 15:39, Nick Coghlan wrote: > However, PEP 572 in its current form takes the position "parent local > scoping is sufficiently useful to make it a required pre-requisite for > adding assignment expressions, but not useful enough to expose as a > new scope declaration primitive",

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27.06.2018 16:49, Steven D'Aprano wrote: On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote: On 6/27/2018 7:08 AM, Chris Angelico wrote: It gets funnier with nested loops. Or scarier. I've lost the ability to distinguish those two. def test(): spam = 1 ham = 2

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27 June 2018 at 23:38, Greg Ewing wrote: > Nick Coghlan wrote: >> >> actually made those semantics available as an explicit >> "parentlocal NAME" declaration ...: >> >> def _list_comp(_outermost_iter): >> parentlocal item >> _result = [] >> for x in _outermost_iter:

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27.06.2018 16:25, Greg Ewing wrote: Ivan Pozdeev via Python-Dev wrote: Using this assigned result elsewhere in the same expression (akin to regex backreferences) is not a part of the basic idea actually. If that's true, then the proposal has mutated into something that has *no* overlap

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 03:41:23PM +0200, Antoine Pitrou wrote: > > Why is this discussion talking about comprehensions at all? > Is there a decent use case for using assignments in comprehensions (as > opposed to language lawyering or deliberate obfuscation)? Yes. The *very first* motivating

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote: > On 6/27/2018 7:08 AM, Chris Angelico wrote: > >It gets funnier with nested loops. Or scarier. I've lost the ability > >to distinguish those two. > > > >def test(): > > spam = 1 > > ham = 2 > > vars = [key1+key2 for key1

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Why is this discussion talking about comprehensions at all? Is there a decent use case for using assignments in comprehensions (as opposed to language lawyering or deliberate obfuscation)? Regards Antoine. On Thu, 28 Jun 2018 01:25:14 +1200 Greg Ewing wrote: > Ivan Pozdeev via Python-Dev

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Nick Coghlan wrote: actually made those semantics available as an explicit "parentlocal NAME" declaration ...: def _list_comp(_outermost_iter): parentlocal item _result = [] for x in _outermost_iter: item = x _result.append(x) return

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Ivan Pozdeev via Python-Dev wrote: Using this assigned result elsewhere in the same expression (akin to regex backreferences) is not a part of the basic idea actually. If that's true, then the proposal has mutated into something that has *no* overlap whatsoever with the use case that started

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27.06.2018 5:36, Guido van Rossum wrote: [This is my one response today] On Mon, Jun 25, 2018 at 12:40 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)

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 26 June 2018 at 02:27, Guido van Rossum wrote: > [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.] Aye, I'm trying to do the same, and deliberately spending some evenings entirely offline is helping with that

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/27/2018 7:08 AM, Chris Angelico wrote: It gets funnier with nested loops. Or scarier. I've lost the ability to distinguish those two. def test(): spam = 1 ham = 2 vars = [key1+key2 for key1 in locals() for key2 in locals()] return vars Wanna guess what that's gonna

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 7:19 PM, Steven D'Aprano wrote: > On Wed, Jun 27, 2018 at 05:52:16PM +1000, Chris Angelico wrote: > >> def test(): >> a = 1 >> b = 2 >> vars = {key: locals()[key] for key in locals()} >> return vars >> >> What would your intuition say? Should this be

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 26.06.2018 1:34, Greg Ewing wrote: 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. What do you mean by

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 05:52:16PM +1000, Chris Angelico wrote: > def test(): > a = 1 > b = 2 > vars = {key: locals()[key] for key in locals()} > return vars > > What would your intuition say? Should this be equivalent to dict(locals()) ? That example is so elegant it makes me

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 08:30:00AM +0100, Paul Moore wrote: > On 27 June 2018 at 07:54, Steven D'Aprano wrote: > > Comprehensions already run partly in the surrounding scope. [...] > > Given the code shown: > > > > def test(): > > a = 1 > > b = 2 > > result = [value for key, value in

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27 June 2018 at 08:52, Chris Angelico wrote: > On Wed, Jun 27, 2018 at 5:30 PM, Paul Moore wrote: >> But test() returns [1, 2]. So does that say (as you claim above) that >> "the comprehension ran in the enclosing scope"? Doesn't it just say >> that the outermost iterable runs in the

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 5:30 PM, Paul Moore wrote: > But test() returns [1, 2]. So does that say (as you claim above) that > "the comprehension ran in the enclosing scope"? Doesn't it just say > that the outermost iterable runs in the enclosing scope? Yes - because the *outermost iterable* runs

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jun 26, 2018 at 10:54:12AM +1200, Greg Ewing wrote: > A decision still needs to be made about whether we *want* > semantics that leak some things but not others. My sense (or bias, if you prefer) is that the answer to that depends on how you word the question. If you talk about

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 27 June 2018 at 07:54, Steven D'Aprano wrote: > Comprehensions already run partly in the surrounding scope. > > I tried to take a survey of people on the Python-List mailing list, so > see what their expectations of comprehension scope was. Disappointingly, > not many people responded, but

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jun 26, 2018 at 05:42:43AM +1000, Chris Angelico wrote: > So. sublocal scopes, like in the earliest versions of PEP 572? > > The wheel turns round and round, and the same spokes come up. It isn't as if comprehensions (and generator expressions) run in a proper separate scope. It is

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On 6/26/2018 10:36 PM, Guido van Rossum wrote: [This is my one response today] Thank you for clearly presenting how you see 'comprehension', 'generator expression' and by implication 'equivalent code'. The latter can either be a definition or an explanation. The difference is subtle but

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

Steven D'Aprano wrote: ":=" is the second most common syntax used for assignment in common programming languages, Yes, but it represents an *ordinary* assigment in those languages. The special way that's being proposed to use it in Python is not obvious. -- Greg

  1   2   >