Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 2018-04-11 04:15, Mike Miller wrote: If anyone is interested I came across this same subject on a blog post and discussion on HN today: - https://www.hillelwayne.com/post/equals-as-assignment/ It says "BCPL also introduced braces as a means of defining blocks.". That bit is wrong, unless "

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Wed, Apr 11, 2018 at 1:15 PM, Mike Miller wrote: > If anyone is interested I came across this same subject on a blog post and > discussion on HN today: > > - https://www.hillelwayne.com/post/equals-as-assignment/ > - https://news.ycombinator.com/item?id=16803874 Those people who say "x = x + 1

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

If anyone is interested I came across this same subject on a blog post and discussion on HN today: - https://www.hillelwayne.com/post/equals-as-assignment/ - https://news.ycombinator.com/item?id=16803874 On 2018-04-02 15:03, Guido van Rossum wrote: IIRC Algol-68 (the lesser-known, more complic

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 9 April 2018 at 01:01, Steven D'Aprano wrote: > On Sun, Apr 08, 2018 at 09:25:33PM +1000, Nick Coghlan wrote: > >> I was writing a new stdlib test case today, and thinking about how I >> might structure it differently in a PEP 572 world, and realised that a >> situation the next version of the

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

write.) Top-posted from my Windows phone From: Nick Coghlan Sent: Sunday, April 8, 2018 6:27 To: Chris Angelico Cc: python-ideas Subject: Re: [Python-ideas] PEP 572: Statement-Local Name Bindings,take three! On 23 March 2018 at 20:01, Chris Angelico wrote: > Apologies for letting this langu

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Apr 8, 2018 at 8:01 AM, Steven D'Aprano wrote: > If we really wanted to keep the sublocal scoping, we could make > list/set/dict displays their own scope too. > > Personally, that's the only argument for sublocal scoping that I like > yet: what happens inside a display should remain insid

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Apr 08, 2018 at 09:25:33PM +1000, Nick Coghlan wrote: > I was writing a new stdlib test case today, and thinking about how I > might structure it differently in a PEP 572 world, and realised that a > situation the next version of the PEP should discuss is this one: > > # Dict display

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 23 March 2018 at 20:01, Chris Angelico wrote: > Apologies for letting this languish; life has an annoying habit of > getting in the way now and then. > > Feedback from the previous rounds has been incorporated. From here, > the most important concern and question is: Is there any other syntax >

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Interesting, thanks. On 2018-04-02 15:03, Guido van Rossum wrote: ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

IIRC Algol-68 (the lesser-known, more complicated version) used 'int x = 0;' to declare a constant and 'int x := 0;' to declare a variable. And there was a lot more to it; see https://en.wikipedia.org/wiki/ALGOL_68#mode:_Declarations. I'm guessing Go reversed this because they want '=' to be the co

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Yes, I first came across := when learning (Turbo) Pascal in the early 90's. However golang managed to screw it up—it only works there as a "short declaration AND assignment" operator. You can't use it twice on the same variable! Boggles the mind how experienced designers came up with that one

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Fri, Mar 30, 2018 at 12:04 PM, Nikolaus Rath wrote: > On Mar 25 2018, Guido van Rossum public.gmane.org> wrote: > > I gotta say I'm warming up to := in preference over 'as', *if* we're > going > > to do this at all (not a foregone conclusion at all). > > I'm surprised that no one has mentione

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mar 25 2018, Guido van Rossum wrote: > I gotta say I'm warming up to := in preference over 'as', *if* we're going > to do this at all (not a foregone conclusion at all). I'm surprised that no one has mentioned it yet, so as a quick datapoint: Go also uses := for assignment, so there's some pr

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/23/2018 03:01 AM, Chris Angelico wrote: Apologies for letting this languish; life has an annoying habit of getting in the way now and then. My simple response to all of this is that it's not worth it. Each new example convinces me more and more that in almost every case, sublocal assi

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

This thread is dead. On Tue, Mar 27, 2018 at 5:40 PM, Rob Cliffe via Python-ideas < python-ideas@python.org> wrote: > > > On 28/03/2018 01:19, Steven D'Aprano wrote: > >> On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas >> wrote: >> >>> On 27/03/2018 16:22, Guido van Rossum w

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 28/03/2018 01:19, Steven D'Aprano wrote: On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas wrote: On 27/03/2018 16:22, Guido van Rossum wrote: The standard reply here is that if you can't tell at a glance whether that's the case, your code is too complex. The Zen of Pyt

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas wrote: > > On 27/03/2018 16:22, Guido van Rossum wrote: > >The standard reply here is that if you can't tell at a glance whether > >that's the case, your code is too complex. The Zen of Python says > >"Namespaces are one honk

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 27/03/2018 16:22, Guido van Rossum wrote: On Tue, Mar 27, 2018 at 7:00 AM, Nick Coghlan > wrote: On 27 March 2018 at 01:57, Guido van Rossum mailto:gu...@python.org>> wrote: > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wr

[Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

> > ... From here, > the most important concern and question is: Is there any other syntax > or related proposal that ought to be mentioned here? I am not sure if this is valid, but perhaps this is an alternative syntax which might be simpler: ``name! expr`` So for example, instead of: stu

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Tue, Mar 27, 2018 at 7:00 AM, Nick Coghlan wrote: > On 27 March 2018 at 01:57, Guido van Rossum wrote: > > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan > wrote: > >> By contrast, the sublocals idea strives to keep the *lifecycle* impact > >> of naming a subexpression as negligible as possib

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 2018-03-23 06:01, Chris Angelico wrote: > https://www.python.org/dev/peps/pep-0572/ > A suggestion: Under the rejected "Special-casing comprehensions", you show "prefix-local-name-bindings": Name bindings that appear before the loop, like: > stuff = [(y, x/y) where y = f(x) for x in range(5

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 27 March 2018 at 01:57, Guido van Rossum wrote: > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan wrote: >> By contrast, the sublocals idea strives to keep the *lifecycle* impact >> of naming a subexpression as negligible as possible - while a named >> subexpression might live a little longer th

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Guido] > ... > Not so fast. There's a perfectly reasonable alternative to sublocal scopes > -- just let it assign to a local variable in the containing scope. That's > the same as what Python does for for-loop variables. That's certainly what I would _expect_ if I never read the docs, conditioned

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/26/2018 04:18 AM, Steven D'Aprano wrote: On Mon, Mar 26, 2018 at 11:14:43AM +0300, Kirill Balunov wrote: Hi Chris, would you mind to add this syntactic form `(expr -> var)` to alternative syntax section, with the same semantics as `(expr as var)`. It seems to me that I've seen this form pr

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 03:33:52PM +0100, Rhodri James wrote: > While my crystal ball is cloudy, I can well imagine beginners becoming > very confused over which symbol to use in which circumstance, and a lot > of swearing when: > > x := f() > if (y = g(x)) is not None: > h(y) > > res

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 26/03/2018 16:57, Guido van Rossum wrote: On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan > wrote: On 26 March 2018 at 14:34, Guido van Rossum mailto:gu...@python.org>> wrote: > Not so fast. There's a perfectly reasonable alternative to sublocal scopes

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan wrote: > On 26 March 2018 at 14:34, Guido van Rossum wrote: > > Not so fast. There's a perfectly reasonable alternative to sublocal > scopes > > -- just let it assign to a local variable in the containing scope. That's > > the same as what Python doe

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 26 March 2018 at 14:34, Guido van Rossum wrote: > Not so fast. There's a perfectly reasonable alternative to sublocal scopes > -- just let it assign to a local variable in the containing scope. That's > the same as what Python does for for-loop variables. Note that for > comprehensions it still

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 26/03/18 02:24, Guido van Rossum wrote: I gotta say I'm warming up to := in preference over 'as',*if* we're going to do this at all (not a foregone conclusion at all). I have the usual objection to glyphs (hard to look up or get help on), but ":=" raises two issues all of its own. * On t

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 02:42:32PM +0300, Kirill Balunov wrote: > I was also thinking about `<-` variant (but with a Haskell in mind), but > with the current Python rules, it seems that it does not fit: Ah, of course not, the dreaded unary operator strikes again! (I was just chatting with Chris

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

2018-03-26 14:18 GMT+03:00 Steven D'Aprano : > That was probably my response to Nick: > > https://mail.python.org/pipermail/python-ideas/2018-March/049472.html > > I compared four possible choices: > > target = default if (expression as name) is None else name > target = default if (name :

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 11:14:43AM +0300, Kirill Balunov wrote: > Hi Chris, would you mind to add this syntactic form `(expr -> var)` to > alternative syntax section, with the same semantics as `(expr as var)`. It > seems to me that I've seen this form previously in some thread (can't find > where)

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 7:14 PM, Kirill Balunov wrote: > Hi Chris, would you mind to add this syntactic form `(expr -> var)` to > alternative syntax section, with the same semantics as `(expr as var)`. It > seems to me that I've seen this form previously in some thread (can't find > where), but it

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Hi Chris, would you mind to add this syntactic form `(expr -> var)` to alternative syntax section, with the same semantics as `(expr as var)`. It seems to me that I've seen this form previously in some thread (can't find where), but it does not appear in alt. syntax section. As for me this form has

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 3:34 PM, Guido van Rossum wrote: > On Sun, Mar 25, 2018 at 6:29 PM, Chris Angelico wrote: >> >> On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum >> wrote: >> > The scope question is far from easy though. I find it particularly >> > grating >> > that an inline assignment

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 6:29 PM, Chris Angelico wrote: > On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum > wrote: > > The scope question is far from easy though. I find it particularly > grating > > that an inline assignment occurs in an 'if' statement, its scope is the > > entire body of the

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Tim] >> I wonder whether Guido remembers this ;-) In the very, very, VERY >> early days, Python didn't have "==". Plain single "=" was used for >> both assignment and equality testing. [Guido] > Wow, I did not remember this. In fact I had to track down the 0.9.1 release > that's somewhere on th

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum wrote: > I gotta say I'm warming up to := in preference over 'as', *if* we're going > to do this at all (not a foregone conclusion at all). So am I, primarily due to its lack of syntactic ambiguities. > The scope question is far from easy though

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 4:40 PM, Tim Peters wrote: > [Chris Angelico ] > > ... > > Not qualitative, but anecdotal: I do sometimes have to remind my > > JavaScript students to check whether they've typed enough equals > > signs. And that's in a language where the normal comparison operator > > is

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Mon, Mar 26, 2018 at 10:40 AM, Tim Peters wrote: > Here's one that baffled an office full of MIT grads for half a day > before I noticed the real problem: > > assert(n=2); > > You can fill in the rest of the story yourself - but you'll miss the > full extent of the agony it caused ;-) I ha

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

[Chris Angelico ] > ... > Not qualitative, but anecdotal: I do sometimes have to remind my > JavaScript students to check whether they've typed enough equals > signs. And that's in a language where the normal comparison operator > is ===. It's *still* not uncommon to see a comparison spelled =. I

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 12:18 AM, Chris Angelico wrote: > [...] > Agreed. I'm currently thinking that I need to do what several people > have suggested and break this into two completely separate PEPs: > > 1) Sublocal namespacing > 2) Assignment expressions > > Sublocal names can be used in a num

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

: On 25 March 2018 at 02:34, Guido van Rossum wrote: > [...] I think we need a short, crisp name for the new variable type. Disposables? -[]z. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 05:00:37PM +1000, Nick Coghlan wrote: > Given the existing namespace stack of > builtin<-global<-nonlocal<-local, one potential short name would be > "sublocal", to indicate that these references are even more local than > locals (they're *so* local, they don't even appe

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 25 March 2018 at 17:18, Chris Angelico wrote: > Agreed. I'm currently thinking that I need to do what several people > have suggested and break this into two completely separate PEPs: > > 1) Sublocal namespacing > 2) Assignment expressions > > Sublocal names can be used in a number of ways. The

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sun, Mar 25, 2018 at 4:34 PM, Guido van Rossum wrote: > This is a super complex topic. There are at least three separate levels of > critique possible, and all are important. Thank you for your detailed post. I'll respond to some of it here, and some more generally below. > First there is the

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 25 March 2018 at 15:34, Guido van Rossum wrote: > > This is a super complex topic. There are at least three separate levels of > critique possible, and all are important. > > First there is the clarity of the PEP. Steven D'Aprano has given you great > detailed feedback here and you should tak

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

This is a super complex topic. There are at least three separate levels of critique possible, and all are important. First there is the clarity of the PEP. Steven D'Aprano has given you great detailed feedback here and you should take it to heart (even if you disagree with his opinion about the sp

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/24/2018 09:27 AM, Rob Cliffe via Python-ideas wrote: On 24/03/2018 14:44, Steven D'Aprano wrote: On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote: For PEP 572, the most directly comparable example is code like this: # Any previous binding of "m" is lost completely on t

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/24/2018 07:44 AM, Steven D'Aprano wrote: I don't think we need sub-function scoping. I think it adds more complexity that outweighs whatever benefit it gives. +1 -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.py

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 24/03/2018 16:02, Steven D'Aprano wrote: Yes, I get functions, and I think function-scope is a sweet spot between too few scopes and too many. Remember the bad old days of BASIC when all variables were application-global? Even if you used GOSUB as a second-rate kind of function, all the var

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 24/03/2018 14:44, Steven D'Aprano wrote: On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote: [...] At a user experience level, the aim of the scoping limitation is essentially to help improve "code snippet portability". Consider the following piece of code: squares = [x**2

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sat, Mar 24, 2018 at 08:49:08PM +1100, Chris Angelico wrote: > > [(spam, spam+1) for x in values for spam in (func(x),)] > > > > [(spam, spam+1) for spam in (func(x) for x in values)] > > > > They are the equivalent to "just add another assignment statement" for > > comprehensions. > >

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote: > > I think that needs justification by more than just "it makes the > > implementation easier". > > Introducing the new scoping behaviour doesn't make the implementation > easier, it makes it harder. [...] Perhaps I had misunderstood

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 3/24/2018 5:49 AM, Chris Angelico wrote: On Sat, Mar 24, 2018 at 3:41 PM, Steven D'Aprano wrote: To keep this a manageable length, I've trimmed vigourously. Apologies in advance if I've been too enthusiastic with the trimming :-) On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 24 March 2018 at 09:49, Chris Angelico wrote: >> Of course we don't want to necessarily impose unreasonable performance >> and maintence costs on any implementation. But surely performance >> cost is a quality of implementation issue. It ought to be a matter of >> trade-offs: is the benefit suf

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sat, Mar 24, 2018 at 3:41 PM, Steven D'Aprano wrote: > To keep this a manageable length, I've trimmed vigourously. Apologies in > advance if I've been too enthusiastic with the trimming :-) > > On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote: > >> No, I haven't yet. Sounds like a

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 24 March 2018 at 14:41, Steven D'Aprano wrote: > On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote: > > >> Just as function-local names shadow global names for the scope of the > > >> function, statement-local names shadow other names for that statement. > > >> (They can technical

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 24 March 2018 at 04:09, Chris Angelico wrote: > On Sat, Mar 24, 2018 at 2:00 AM, Steven D'Aprano > wrote: > > I see you haven't mentioned anything about Nick Coglan's (long ago) > > concept of a "where" block. If memory serves, it would be something > > like: > > > > value = x**2 + 2*x wh

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

To keep this a manageable length, I've trimmed vigourously. Apologies in advance if I've been too enthusiastic with the trimming :-) On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote: > No, I haven't yet. Sounds like a new section is needed. Thing is, > there's a HUGE family of C-li

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sat, Mar 24, 2018 at 2:00 AM, Steven D'Aprano wrote: > On Fri, Mar 23, 2018 at 09:01:01PM +1100, Chris Angelico wrote: > >> PEP: 572 >> Title: Syntax for Statement-Local Name Bindings > [...] >> Abstract >> >> >> Programming is all about reusing code rather than duplicating it. > > I d

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Fri, Mar 23, 2018 at 09:01:01PM +1100, Chris Angelico wrote: > PEP: 572 > Title: Syntax for Statement-Local Name Bindings [...] > Abstract > > > Programming is all about reusing code rather than duplicating it. I don't think that editorial comment belongs here, or at least, it is wa

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 23/03/18 10:01, Chris Angelico wrote: Apologies for letting this languish; life has an annoying habit of getting in the way now and then. Feedback from the previous rounds has been incorporated. From here, the most important concern and question is: Is there any other syntax or related propos

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Fri, Mar 23, 2018 at 9:38 PM, Paul Moore wrote: > On 23 March 2018 at 10:01, Chris Angelico wrote: >> # ... except when function bodies are involved... >> if (input("> ") as cmd): >> def run_cmd(): >> print("Running command", cmd) # NameError >> >> # ... but fun

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 23 March 2018 at 10:01, Chris Angelico wrote: > # ... except when function bodies are involved... > if (input("> ") as cmd): > def run_cmd(): > print("Running command", cmd) # NameError > > # ... but function *headers* are executed immediately > if (input(">

[Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

Apologies for letting this languish; life has an annoying habit of getting in the way now and then. Feedback from the previous rounds has been incorporated. From here, the most important concern and question is: Is there any other syntax or related proposal that ought to be mentioned here? If this

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 03/02/2018 11:11 PM, Nick Coghlan wrote: On 3 March 2018 at 03:51, Ethan Furman wrote: Ah, right. Since the PEP primarily covers comprehensions, but then went on to discuss multi-line statements, I had forgotten the comprehension part. The answer is easy: assignment expressions in comp

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 3 March 2018 at 03:51, Ethan Furman wrote: > On 03/02/2018 02:47 AM, Nick Coghlan wrote: > >> On 2 March 2018 at 16:39, Ethan Furman wrote: >> >>> On 03/01/2018 09:08 PM, Nick Coghlan wrote: >>> >> > Adding statement local variables into that mix *without* some form of syntactic marker wo

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 3 March 2018 at 10:09, Greg Ewing wrote: > Nick Coghlan wrote: > >> I don't think it should be possible to close over statement locals. >> > > Why not? I gave a more detailed answer to that in https://mail.python.org/pipermail/python-ideas/2018-March/049138.html, but the short version is: *

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Nick Coghlan wrote: I don't think it should be possible to close over statement locals. Why not? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/ps

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 03/02/2018 02:47 AM, Nick Coghlan wrote: On 2 March 2018 at 16:39, Ethan Furman wrote: On 03/01/2018 09:08 PM, Nick Coghlan wrote: Adding statement local variables into that mix *without* some form of syntactic marker would mean taking an already complicated system, and making it even har

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Sorry, answer to an old post but I just realized I didn't use the correct email address... (See below to see which message I'm answering). That's what I said on github, there are two different use cases : *ListComp* Vs *AnyExpressions* : 1) List comprehension : [y+2 for x in range(5) for y in [

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 14:23, Nick Coghlan wrote: > On 2 March 2018 at 23:26, Paul Moore wrote: >> >> Adding "mustn't just be another way to spell name = expr" to the >> requirements is an extra requirement - and arguably one that >> contradicts the original requirement which was "find a way to allow

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Hi all, I would like to observe that there is already a way to bind names in an expression: a = (lambda b: [b, b])(b=f()) Currently this is not so performant, but there is nothing stopping the compiler from special-casing such an IIFE (Immediate Invoked Function Expression), to use the Javascrip

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 23:26, Paul Moore wrote: > Adding "mustn't just be another way to spell name = expr" to the > requirements is an extra requirement - and arguably one that > contradicts the original requirement which was "find a way to allow > name = expr in expressions". > I consider allowing

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 12:48, Nick Coghlan wrote: > The design intent related rationale stems from the fact that closed over > references can live for an arbitrarily long time (as can regular function > locals in a generator or coroutine), and I think statement locals should be > as reliably ephemeral

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 21:50, Paul Moore wrote: > On 2 March 2018 at 11:15, Nick Coghlan wrote: > > On 2 March 2018 at 19:05, Paul Moore wrote: > >> > >> The problem with statement local variables is that the extent over > >> which the name is in scope is not as clear to the human reader (the > >>

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 11:15, Nick Coghlan wrote: > On 2 March 2018 at 19:05, Paul Moore wrote: >> >> The problem with statement local variables is that the extent over >> which the name is in scope is not as clear to the human reader (the >> rules the *compiler* follows may be precise, but they aren

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 19:05, Paul Moore wrote: > The problem with statement local variables is that the extent over > which the name is in scope is not as clear to the human reader (the > rules the *compiler* follows may be precise, but they aren't obvious > to the human reader - that's the root of

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 16:39, Ethan Furman wrote: > On 03/01/2018 09:08 PM, Nick Coghlan wrote: > >> Adding statement local variables into that mix *without* some form of >> syntactic marker would mean taking an already >> complicated system, and making it even harder to reason about correctly >> (es

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2 March 2018 at 05:08, Nick Coghlan wrote: > On 1 March 2018 at 19:30, Paul Moore wrote: >> >> Agreed. This feels far to much like Perl's "sigils" that attach to a >> name ($var is a scalar, @var is a list, etc). Strong -1 from me. > > While that's a fair criticism, one of the current challeng

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Fri, Mar 2, 2018 at 5:39 PM, Ethan Furman wrote: > Seems like it would far easier and (IMHO) more useful to scale the proposal > back from a statement scope to simple expression assignment, and the > variable is whatever scope it would have been if assigned to outside the > expression (default

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 03/01/2018 09:08 PM, Nick Coghlan wrote: On 1 March 2018 at 19:30, Paul Moore On 1 March 2018 at 06:40, Chris Angelico wrote: On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan wrote: Since ".NAME" is illegal for both variable and attribute names, this makes the fact statement locals are a dist

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 1 March 2018 at 19:30, Paul Moore wrote: > On 1 March 2018 at 06:40, Chris Angelico wrote: > > On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan wrote: > >> Since ".NAME" is illegal for both variable and attribute names, this > makes > >> the fact statement locals are a distinct namespace visible

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 2:47 PM, Greg Ewing wrote: > On 28 February 2018 at 21:48, Robert Vanden Eynde >> wrote: >> >> Isn't it easier to talk on a forum? >>> >> > For me, the fact that all the mailing lists I subscribe to > feed into one input queue is a feature, not a bug. It means > I can easi

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 28 February 2018 at 21:48, Robert Vanden Eynde wrote: Isn't it easier to talk on a forum? For me, the fact that all the mailing lists I subscribe to feed into one input queue is a feature, not a bug. It means I can easily keep abreast of developments in many areas at once, without having t

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 01/03/2018 06:47, Chris Angelico wrote: This is the kind of ambiguity of intent that goes away if statement locals are made syntactically distinct in addition to being semantically distinct: .a = (2 as .a) # Syntax error (persistent bindings can't target statement locals) a = (2 as

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Nick Coghlan writes: > for .i in range(10): > print(.i) # This is fine > print(.i) # This is an error (unless an outer statement also sets .i) That's one heck of a lot of grit on Tim's screen! ___ Python-ideas mailing list Python-idea

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Nick Coghlan writes: > for .i in range(10): > print(.i) # This is fine > print(.i) # This is an error (unless an outer statement also sets .i) That's one heck of a lot of grit on Tim's screen! ___ Python-ideas mailing list Python-idea

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Chris Angelico writes: > Memoization can only be done for pure functions. True, but when for impure f you naively construct a list [f(x), f(x)], substituting [(f(x) as wrong), wrong] is just [wrong, wrong] ;-), because the side effect doesn't get reevaluated. Steve

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

Reply-To set to *me*. I don't really think this idea has legs at this point. It's been discussed before (it even has a SIG), but that ran out of steam and the move to Mailman 3 (whose archiver provides a more forum-like interface) is more or less imminent anyway, so it's kind of moot. I'm happy

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 1 March 2018 at 06:40, Chris Angelico wrote: > On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan wrote: >> Since ".NAME" is illegal for both variable and attribute names, this makes >> the fact statement locals are a distinct namespace visible to readers as >> well as to the compiler, and also redu

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 28 February 2018 at 21:48, Robert Vanden Eynde wrote: > We are currently like a dozen of people talking about multiple sections of a > single subject. > > Isn't it easier to talk on a forum? Not for me, certainly. I could probably learn how to effectively work with a forum, but as of right now

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 3:54 PM, Nick Coghlan wrote: > On 1 March 2018 at 06:00, Chris Angelico wrote: >> >> On Thu, Mar 1, 2018 at 6:35 AM, Brendan Barnwell >> wrote: >> > On 2018-02-28 07:18, Chris Angelico wrote: >> >> >> >> Except that assignment is evaluated RHS before LHS as part of a singl

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 3:31 PM, Nick Coghlan wrote: > On 28 February 2018 at 08:27, Chris Angelico wrote: >> 2. The current implementation [1] implements statement-local names using >>a special (and mostly-invisible) name mangling. This works perfectly >>inside functions (including list

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 1 March 2018 at 06:34, Chris Angelico wrote: > On Thu, Mar 1, 2018 at 7:28 AM, Paul Moore wrote: > > I've no idea how that would work under statement-local names either, > though. > > > > boom = lambda: boom() > > boom() > > > > is just an infinite recursion. I'm less sure that the as

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 1 March 2018 at 06:00, Chris Angelico wrote: > On Thu, Mar 1, 2018 at 6:35 AM, Brendan Barnwell > wrote: > > On 2018-02-28 07:18, Chris Angelico wrote: > >> > >> Except that assignment is evaluated RHS before LHS as part of a single > >> statement. When Python goes to look up the name "a" to

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 28 February 2018 at 08:27, Chris Angelico wrote: > This is a suggestion that comes up periodically here or on python-dev. > This proposal introduces a way to bind a temporary name to the value > of an expression, which can then be used elsewhere in the current > statement. > > The nicely-rende

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On 2018-02-28 02:46, Matt Arcidy wrote: > From readability, the examples put forth have been to explain the > advantage, with which I agree.  However, i do not believe this scales > well. > > [(foo(x,y) as g)*(bar(y) as i) + g*foo(x,a) +baz(g,i) for x... for y...] > > That's 3 functions, 2 iterat

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Tue, Feb 27, 2018 at 11:46 PM, Matt Arcidy wrote: > From readability, the examples put forth have been to explain the > advantage, with which I agree. However, i do not believe this scales well. > > [(foo(x,y) as g)*(bar(y) as i) + g*foo(x,a) +baz(g,i) for x... for y...] > This definitely lo

  1   2   >