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 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 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

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

After dozens of posts and a wide variety of useful opinions and concerns being raised, here is the newest version of PEP 572 for your debating pleasure. Formatted version: https://www.python.org/dev/peps/pep-0572/ There are now several more examples, greater clarity in edge cases, and improved w

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 version 2: Statement-Local Name Bindings

On 2 March 2018 at 11:43, Chris Angelico wrote: > After dozens of posts and a wide variety of useful opinions and > concerns being raised, here is the newest version of PEP 572 for your > debating pleasure. This is a distinct improvement - thanks for incorporating the varied feedback so well. I

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 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 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

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 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 version 2: Statement-Local Name Bindings

On Fri, Mar 2, 2018 at 10:56 PM, Paul Moore wrote: > On 2 March 2018 at 11:43, Chris Angelico wrote: >> After dozens of posts and a wide variety of useful opinions and >> concerns being raised, here is the newest version of PEP 572 for your >> debating pleasure. > > This is a distinct improvement

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

On 02/03/18 11:43, Chris Angelico wrote: After dozens of posts and a wide variety of useful opinions and concerns being raised, here is the newest version of PEP 572 for your debating pleasure. I haven't said this yet, so thanks Chris for putting this all together. Even if the result is a reje

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

+1 on extracting the big win for "if" and "while" (the regex case is wonderul). It would be see as an "extended if/while" rather than a general statement assignation. +1 on list comprehensions, even if I prefer the [(y, x/y) with y = f(x) for x in range(5)] or [(y, x/y) for x in range(5) with y =

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 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 1:53 AM, Rhodri James wrote: > On 02/03/18 11:43, Chris Angelico wrote: >> >> After dozens of posts and a wide variety of useful opinions and >> concerns being raised, here is the newest version of PEP 572 for your >> debating pleasure. > > > I haven't said this yet, so than

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

I remain -1 on the PEP, but thank you very much Chris for the great work writing it and the extra clarifications in it. The part I like most about the proposal is the use in blocks, like: if (re.match(...) as m): print(m.groups(0)) if (input("> ") as cmd): def run_cmd(cmd=cmd): # Capture

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

[Python-ideas] breakpoint(): print(*args, **kwargs) before entering pdb

I played around with a newer Python build, but when using the new `breakpoint` builtin, I missed my weapon of choice: dirty print-debugging. I suggest we combine forces and make the default `sys.breakpointhook` forward *args and **kwargs to print before entering pdb. - Carl Bordum Hansen ___

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

On 03/02/2018 03:43 AM, Chris Angelico wrote: PEP: 572 Title: Syntax for Statement-Local Name Bindings Author: Chris Angelico Looks nice, thanks for the updates! Alternative proposals = 6. Allowing ``(EXPR as NAME)`` to assign to any form of name. This is exactl

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

2018-03-02 7:03 GMT-08:00 Robert Vanden Eynde : > +1 on extracting the big win for "if" and "while" (the regex case is > wonderul). It would be see as an "extended if/while" rather than a general > statement assignation. > > I wonder if we could have a more limited change to the language that woul

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

On 2018-03-02 03:43, Chris Angelico wrote: After dozens of posts and a wide variety of useful opinions and concerns being raised, here is the newest version of PEP 572 for your debating pleasure. After following the discussion here, I think I've come to the conclusion that something like "EXP

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

On Sat, Mar 3, 2018 at 5:27 AM, Jelle Zijlstra wrote: > > > 2018-03-02 7:03 GMT-08:00 Robert Vanden Eynde : >> >> +1 on extracting the big win for "if" and "while" (the regex case is >> wonderul). It would be see as an "extended if/while" rather than a general >> statement assignation. >> > > I wo

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

On 03/02/2018 08:04 AM, Chris Angelico wrote: On Sat, Mar 3, 2018 at 1:53 AM, Rhodri James wrote: On 02/03/18 11:43, Chris Angelico wrote: # Compound statements usually enclose everything... if (re.match(...) as m): print(m.groups(0)) print(m) # NameError This (a

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

On 03/02/2018 09:34 AM, David Mertz wrote: So right now, I can do these: class bind(object): def __init__(self, *args): self.args = args def __enter__(self): return self.args[0] if len(self.args)==1 else self.args def __exit__(self, *args

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

On Sat, Mar 3, 2018 at 5:30 AM, Brendan Barnwell wrote: > But if that's the case, maybe what we want is actually another thing > that's been discussed many times on this list, namely something like a > with-block that can define "super-local" variables that disappear at the end > of the bl

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

On Fri, Mar 2, 2018 at 10:44 AM, Ethan Furman wrote: > On 03/02/2018 09:34 AM, David Mertz wrote: > >> >>> with bind(sqrt(2), log(2)) as (a, b): >> ... print(a, b, a+b) >> 1.4142135623730951 0.6931471805599453 2.1073607429330403 >> >> This would cover 98% of the cases that I would

Re: [Python-ideas] breakpoint(): print(*args, **kwargs) before entering pdb

On Fri, Mar 2, 2018 at 12:00 PM, Carl Bordum Hansen wrote: > I played around with a newer Python build, but when using the new > `breakpoint` builtin, I missed my weapon of choice: dirty print-debugging. > > I suggest we combine forces and make the default `sys.breakpointhook` > forward *args and

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

On 02/03/18 18:27, Jelle Zijlstra wrote: 2018-03-02 7:03 GMT-08:00 Robert Vanden Eynde : Guys, please don't email to me *and* the mailing list. Getting two copies of your deathless prose makes me less likely to pay attention to you, not more. -- Rhodri James *-* Kynesim Ltd ___

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

@Rhodri, this is what Everybody does because you hit the "reply to all" button, but, we don't receive two copies on the mail, I don't know why (but that's a good thing). Le 2 mars 2018 20:48, "Rhodri James" a écrit : On 02/03/18 18:27, Jelle Zijlstra wrote: > 2018-03-02 7:03 GMT-08:00 Robert Va

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

On Sat, Mar 3, 2018 at 6:55 AM, Robert Vanden Eynde wrote: > @Rhodri, this is what Everybody does because you hit the "reply to all" > button, but, we don't receive two copies on the mail, I don't know why (but > that's a good thing). > > Le 2 mars 2018 20:48, "Rhodri James" a écrit : > > On 02/0

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

On Fri, Mar 2, 2018 at 2:56 PM Robert Vanden Eynde wrote: > @Rhodri, this is what Everybody does because you hit the "reply to all" > button, but, we don't receive two copies on the mail, I don't know why (but > that's a good thing). > > Le 2 mars 2018 20:48, "Rhodri James" a écrit : > > On 02/0

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

On Fri, Mar 2, 2018 at 10:27 AM, Jelle Zijlstra wrote: > > I wonder if we could have a more limited change to the language that would > allow only the as/while use cases. Specifically, that means we could do: > > while do_something() as x: > print(x) > ​The "while" case is the only part of t

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

On Sat, Mar 3, 2018 at 7:04 AM, Eric Fahlgren wrote: > > On Fri, Mar 2, 2018 at 10:27 AM, Jelle Zijlstra > wrote: >> >> >> I wonder if we could have a more limited change to the language that would >> allow only the as/while use cases. Specifically, that means we could do: >> >> while do_somethin

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

On 2018-03-02 12:20, Chris Angelico wrote: On Sat, Mar 3, 2018 at 7:04 AM, Eric Fahlgren wrote: On Fri, Mar 2, 2018 at 10:27 AM, Jelle Zijlstra wrote: I wonder if we could have a more limited change to the language that would allow only the as/while use cases. Specifically, that means we c

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

Le 2 mars 2018 21:02, "Chris Angelico" a écrit : On Sat, Mar 3, 2018 at 6:55 AM, Robert Vanden Eynde wrote: > @Rhodri, this is what Everybody does because you hit the "reply to all" > button, but, we don't receive two copies on the mail, I don't know why (but > that's a good thing). > > Le 2 mar

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

On 03/02/2018 12:47 PM, Robert Vanden Eynde wrote: @Chris @Rohdri (@Jonathan below) For morons like me who didn't know what "top-posting" was, I went on Wikipedia (https://en.m.wikipedia.org/wiki/Posting_style ). You looked it up and researched

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

On Sat, Mar 3, 2018 at 7:31 AM, Brendan Barnwell wrote: > On 2018-03-02 12:20, Chris Angelico wrote: >> >> On Sat, Mar 3, 2018 at 7:04 AM, Eric Fahlgren >> wrote: >>> >>> >>> On Fri, Mar 2, 2018 at 10:27 AM, Jelle Zijlstra >>> >>> wrote: I wonder if we could have a more limit

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

Le 2 mars 2018 22:03, "Ethan Furman" a écrit : On 03/02/2018 12:47 PM, Robert Vanden Eynde wrote: @Chris @Rohdri (@Jonathan below) > > For morons like me who didn't know what "top-posting" was, I went on > Wikipedia > (https://en.m.wikipedia.org/wiki/Posting_style < > https://en.m.wikipedia.org/

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

On Sat, Mar 3, 2018 at 7:47 AM, Robert Vanden Eynde wrote: >> And please, don't top-post. Again, if your mail client encourages top >> posting, either override it, or get a better one. > > @Chris @Rohdri (@Jonathan below) > > For morons like me who didn't know what "top-posting" was, I went on > W

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

Le 2 mars 2018 22:13, "Chris Angelico" a écrit : On Sat, Mar 3, 2018 at 7:47 AM, Robert Vanden Eynde wrote: >> And please, don't top-post. Again, if your mail client encourages top >> posting, either override it, or get a better one. > > @Chris @Rohdri (@Jonathan below) > > For morons like me wh

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

On Fri, Mar 2, 2018 at 12:20 PM, Chris Angelico wrote: > How often do you have a loop like this where you actually want to > capture the exact condition? I can think of two: regular expressions > (match object or None), and socket read (returns empty string on EOF). > This simplified form is ONLY

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

Le 2 mars 2018 22:21, "Robert Vanden Eynde" a écrit : Le 2 mars 2018 22:13, "Chris Angelico" a écrit : On Sat, Mar 3, 2018 at 7:47 AM, Robert Vanden Eynde wrote: >> And please, don't top-post. Again, if your mail client encourages top >> posting, either override it, or get a better one. > > @C

[Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

PEP 572 as it stands seems to have many problems: * Asymmetry between the first and subsequent uses of the bound value * Embedded as-clauses are subtle and hard to spot * Ever more convoluted semantics are being invented to address percieved pitfalls Alternative proposal

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

Chris Angelico wrote: It would NOT work for anything where the bool() of the desired object doesn't exactly match the loop's condition. while condition(x) where x = something(): ... -- Greg ___ Python-ideas mailing list Python-ideas@python.o

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] An alternative to PEP 572's Statement-Local Name Bindings

The syntax you propose is already in the Alternate syntax and there is an implementation at https://github.com/thektulu/cpython/tree/where-expr Already discussed, but no conclusion, for me I see two different proposals, the "[y for x in range(5) with y = x+1]" in comprehensions list, and the case

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

On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing wrote: > Chris Angelico wrote: >> >> It would NOT work for anything where the bool() of >> the desired object doesn't exactly match the loop's condition. > > >while condition(x) where x = something(): > ... > And we're back to needing a new ke

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

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] An alternative to PEP 572's Statement-Local Name Bindings

On 3 March 2018 at 11:36, Greg Ewing wrote: > PEP 572 as it stands seems to have many problems: > > * Asymmetry between the first and subsequent > uses of the bound value > * Embedded as-clauses are subtle and hard to spot > * Ever more convoluted semantics are being invented > to address per

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

On 3 March 2018 at 11:36, Greg Ewing wrote: > 1. Name bindings local to an expression: > >roots = ([(-b-r)/(2*a), (-b+r)/(2*a)] where r = sqrt(b*b-4*a*c)) > > B. In an expression, surrounded by parentheses for > disambiguation. Bindings are visible only within the > parentheses. > I'll note