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

On Wed, Feb 28, 2018 at 6:46 PM, Matt Arcidy wrote: > I have been struggling to justify the need based on what I have read. I > hope this isn't a dupe, I only saw caching mentioned in passing. > > Also please excuse some of the naive generalizations below for illustrative > purposes. > > Is there

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

True, but it's also extremely wordy. Your two proposed syntaxes, if I have this correct, are: 1) '(' 'with' EXPR 'as' NAME ':' EXPR ')' 2) '(' EXPR 'with' EXPR 'as' NAME ')' Of the two, I prefer the first, as the second has the same problem as the if/else expression: execution is middle-first. It

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

I appreciate that point as it is what I must be misunderstanding. I believe the performance speed up of [((f(x) as h), g(h)) for x range(10)] is that there are 10 calls to compute f, not 20. You can do this with a dictionary right now, at least for the example we're talking about: [(d[x], g(d[x])

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

On Wed, Feb 28, 2018 at 8:55 PM, Matt Arcidy wrote: > I appreciate that point as it is what I must be misunderstanding. > > I believe the performance speed up of [((f(x) as h), g(h)) for x > range(10)] is that there are 10 calls to compute f, not 20. > > You can do this with a dictionary right now

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

On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote: > Considering the 3rd syntax : > '(' EXPR 'with' NAME '=' EXPR ')' > > Wouldn't have the problem of "execution being middle first and would clearly > differenciate the "with NAME = CONTEXT" from the "with CONTEXT as NAME:" > statement. I

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

On 27 February 2018 at 22: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-render

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

On Wed, Feb 28, 2018 at 10:49 PM, Paul Moore wrote: > On 27 February 2018 at 22: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 e

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

28.02.18 00:27, Chris Angelico пише: Example usage = These list comprehensions are all approximately equivalent:: # Calling the function twice stuff = [[f(x), f(x)] for x in range(5)] The simplest equivalent of [f(x), f(x)] is [f(x)]*2. It would be worth to use less tri

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

On Thu, Mar 1, 2018 at 12:49 AM, Serhiy Storchaka wrote: > 28.02.18 00:27, Chris Angelico пише: >> >> Example usage >> = >> >> These list comprehensions are all approximately equivalent:: >> >> # Calling the function twice >> stuff = [[f(x), f(x)] for x in range(5)] > > > The

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

2018-02-28 16:49 GMT+03:00 Serhiy Storchaka : > 28.02.18 00:27, Chris Angelico пише: > >> Example usage >> = >> >> These list comprehensions are all approximately equivalent:: >> >> # Calling the function twice >> stuff = [[f(x), f(x)] for x in range(5)] >> > > Other options

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

28.02.18 16:14, Kirill Balunov пише: 2018-02-28 16:49 GMT+03:00 Serhiy Storchaka >: Other options:     stuff = [[y, y] for y in (f(x) for x in range(5))] Why not `stuff = [[y, y] for y in map(f, range(5))]`? It is currently the fastest and most readable v

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

28.02.18 16:06, Chris Angelico пише: On Thu, Mar 1, 2018 at 12:49 AM, Serhiy Storchaka wrote: Other options: g = (f(x) for x in range(5)) stuff = [[y, y] for y in g] That's the same as the one-liner, but with the genexp broken out. Not sure it helps much as examples go? It is mor

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

On Thu, Mar 1, 2018 at 1:51 AM, Serhiy Storchaka wrote: > 28.02.18 16:06, Chris Angelico пише: >> >> On Thu, Mar 1, 2018 at 12:49 AM, Serhiy Storchaka >> wrote: >>> >>> Other options: >>> >>> g = (f(x) for x in range(5)) >>> stuff = [[y, y] for y in g] >> >> >> That's the same as the on

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

On 02/27/2018 09:23 PM, Chris Angelico wrote: On Wed, Feb 28, 2018 at 2:47 PM, Rob Cliffe via Python-ideas wrote: And here's a thought: What are the semantics of a = (42 as a) # Of course a linter should point this out too At first I thought this was also a laborious synonym for "a=42".

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

28.02.18 16:56, Chris Angelico пише: def g(): for x in range(5): y = f(x) yield [y, y] stuff = list(g) You're not the first to mention this, but I thought it basically equivalent to the "expand into a loop" form. Is it really beneficial to expa

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

On Thu, Mar 1, 2018 at 2:10 AM, Ethan Furman wrote: > dis.dis may be great, but so is running the function so everyone can see the > output. ;) Oh, sorry. >>> f() 1 > If I understood your explanation, `print(a)` produces `1` ? That seems > wrong -- the point of statement-local name bindings i

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

On Thu, Mar 1, 2018 at 2:16 AM, Serhiy Storchaka wrote: > 28.02.18 16:56, Chris Angelico пише: > > def g(): > for x in range(5): > y = f(x) > yield [y, y] > stuff = list(g) You're not the first to mention

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

28.02.18 08:52, Chris Angelico пише: A new version of the PEP has been pushed, and should be live within a few minutes. https://www.python.org/dev/peps/pep-0572/ Whatever I've missed, do please let me know. This document should end up incorporating, or at least mentioning, all of the proposals

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

On Thu, Mar 1, 2018 at 2:20 AM, Serhiy Storchaka wrote: > 28.02.18 08:52, Chris Angelico пише: >> >> A new version of the PEP has been pushed, and should be live within a >> few minutes. >> >> https://www.python.org/dev/peps/pep-0572/ >> >> Whatever I've missed, do please let me know. This documen

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

On 02/28/2018 02:43 AM, Chris Angelico wrote: On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote: 3) "C problem that an equals sign in an expression can now create a name binding, rather than performing a comparison." The "=" does variable assignement already, and there is no grammar p

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

On Thu, Mar 1, 2018 at 2:25 AM, Ethan Furman wrote: > On 02/28/2018 02:43 AM, Chris Angelico wrote: >> >> On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote: > > >>> 3) "C problem that an equals sign in an expression can now create a name >>> binding, rather than performing a comparison."

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

On 28 February 2018 at 15:18, Chris Angelico wrote: >> a = (2 as a) >> >> there is a temporary variable 'a', which gets assigned 2, and the SLNB is >> evaluated as 2, which should then get assigned back to the local variable >> 'a'. In other words, the final print from `f()` above should be

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

On Thu, Mar 1, 2018 at 2:46 AM, Paul Moore wrote: > On 28 February 2018 at 15:18, Chris Angelico wrote: > >>> a = (2 as a) >>> >>> there is a temporary variable 'a', which gets assigned 2, and the SLNB is >>> evaluated as 2, which should then get assigned back to the local variable >>> 'a'.

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

On 28 February 2018 at 13:45, Chris Angelico wrote: > On Wed, Feb 28, 2018 at 10:49 PM, Paul Moore wrote: >> While there's basically no justification for doing so, it should be >> noted that under this proposal, 1 as x) as y) as z) as w) as >> v) as u) as t) as s) is valid. Of course, "y

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

On 02/27/2018 02:27 PM, Chris Angelico wrote: PEP: 572 Because: a = (2 as a) does not evaluate to 2 and because some statements, such as 'for' and 'while' can cover many, many lines (leaving plenty of potential for confusion over which variable disappear at the end and which persist):

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

The PEP says: > Omitting the parentheses from this PEP's proposed syntax introduces many > syntactic ambiguities. > and: As the name's scope extends to the full current statement, even a block > statement, this can be used to good effect in the header of an if or while > statement Will the

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

On 28/02/2018 05:23, Chris Angelico wrote: If calling `f(x)` is expensive or has side effects, the clean operation of the list comprehension gets muddled. Using a short-duration name binding retains the simplicity; while the extra `for` loop does achieve this, it does so at the cost of dividi

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

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 store it (as the final step of the assignment), the SLNB is still active (it's still the same statement - note that this is NOT

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

On Thu, Mar 1, 2018 at 3:30 AM, Paul Moore wrote: > On 28 February 2018 at 13:45, Chris Angelico wrote: >> On Wed, Feb 28, 2018 at 10:49 PM, Paul Moore wrote: > >>> While there's basically no justification for doing so, it should be >>> noted that under this proposal, 1 as x) as y) as z)

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

On Thu, Mar 1, 2018 at 5:03 AM, Kirill Balunov wrote: > > The PEP says: > >> >> Omitting the parentheses from this PEP's proposed syntax introduces many >> syntactic ambiguities. > > > and: > >> As the name's scope extends to the full current statement, even a block >> statement, this can be used

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

On Thu, Mar 1, 2018 at 5:09 AM, Rob Cliffe via Python-ideas wrote: > > > On 28/02/2018 05:23, Chris Angelico wrote: >> >> >>> If calling `f(x)` is expensive or has side effects, the clean operation >>> of >>> the list comprehension gets muddled. Using a short-duration name binding >>> retains the

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

Thanks for taking the time to write this PEP, Chris, even though I'm -1 on the idea. I'm glad to just have this as a historical document for the idea. On Tue, 27 Feb 2018 at 22:53 Chris Angelico wrote: > On Wed, Feb 28, 2018 at 4:52 PM, Robert Vanden Eynde > wrote: > > Hello Chris and Rob, > >

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

On Thu, Mar 1, 2018 at 6:54 AM, Brett Cannon wrote: > Thanks for taking the time to write this PEP, Chris, even though I'm -1 on > the idea. I'm glad to just have this as a historical document for the idea. I'm going to get a reputation for writing up PEPs for dead ideas. PEP 463 (exception-catch

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

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 store it (as >> the final step of the assignment), the SLNB is

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

For what its worth, I'm +1 on it. I actually like that it would allow: while (something() as var): something_else(var) ...without being a bug magnet. The bug magnet isn't the assignment of a name in the condition of a while loop, it's the fact that assignment is a simple typo away from comp

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

On 28 February 2018 at 19:41, Chris Angelico wrote: > On Thu, Mar 1, 2018 at 3:30 AM, Paul Moore wrote: > Here's another equally untested piece of code: > > [(-b + (sqrt(b*b - 4*a*c) as disc)) / (2*a), (-b - disc) / (2*a)] Yeah, that's a good real world example. And IMO it hides the symmetry be

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

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 version is. > Or the alternative form > > ((lambda: boom()) a

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

On 28 February 2018 at 20:16, Alex Walters wrote: > For what its worth, I'm +1 on it. > > I actually like that it would allow: > > while (something() as var): > something_else(var) > > ...without being a bug magnet. The bug magnet isn't the assignment of a > name in the condition of a while l

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

On 02/28/2018 12:16 PM, Alex Walters wrote: For what its worth, I'm +1 on it. I actually like that it would allow: while (something() as var): something_else(var) ...without being a bug magnet. The bug magnet isn't the assignment of a name in the condition of a while loop, it's the fact

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

Le 28 févr. 2018 11:43, "Chris Angelico" a écrit : > It's still right-to-left, which is as bad as middle-outward once you > combine it with normal left-to-right evaluation. Python has very > little of this [..] I agree [] >> 2) talking about the implementation of thektulu in the "where =" p

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

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? *Am I the only one* who thinks mailing list isn't easy when lots of people talking about multiple subjects? Of course we would put the link in the mailing list so that

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

-0 unless archived appropriately. List is the standard for decades. but I guess things change and I get old. On Wed, Feb 28, 2018, 13:49 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

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

On Thu, Mar 1, 2018 at 8:38 AM, Robert Vanden Eynde wrote: > Le 28 févr. 2018 11:43, "Chris Angelico" a écrit : >> If you aren't using the variable multiple times, there's no point >> giving it a name. Unless I'm missing something here? > > Yes, variables are not there "just because we reuse them

[Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

That should probably be its own thread From: Python-ideas [mailto:[email protected]] On Behalf Of Robert Vanden Eynde Sent: Wednesday, February 28, 2018 4:48 PM Cc: python-ideas Subject: Re: [Python-ideas] PEP 572: Statement-Local Name Bindings We ar

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

On 02/28/2018 01:48 PM, 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? No. *Am I the only one* who thinks mailing list isn't easy when lots of people talking about multiple subject

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

On Thu, Mar 1, 2018 at 8:53 AM, Matt Arcidy wrote: > -0 unless archived appropriately. List is the standard for decades. but I > guess things change and I get old. Archived, searchable, and properly threaded AND properly notifying the correct participants. Every few years, a spiffy new thing co

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

By "thread" you mean like "email thread" ? Meaning when I want to talk about multiple stuffs, I send multiple mails with different "Subject Lines" ? I have like multiple issues : - Base Syntax (multiple choice, list pros and cons) - Extended Syntax (what about parenthesis, and multiple assignement

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

The topic has been discussed to death with all possible pros and cons. I've published my personal collection of pros and cons at http://phdru.name/Software/mail-vs-web.html And my personal bottom line is: I still prefer mailing lists but I know their advantages and disadvantages and I've invest

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

"This page was intentionally left blank." > -Original Message- > From: Python-ideas [mailto:python-ideas-bounces+tritium- > [email protected]] On Behalf Of Oleg Broytman > Sent: Wednesday, February 28, 2018 5:12 PM > To: [email protected] > Subject: Re: [Python-ideas] Medium

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

Oops, sorry, fixed. On Wed, Feb 28, 2018 at 05:18:43PM -0500, Alex Walters wrote: > "This page was intentionally left blank." > > > -Original Message- > > From: Python-ideas [mailto:python-ideas-bounces+tritium- > > [email protected]] On Behalf Of Oleg Broytman > > Sent: Wednes

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

if Linux kernel can handle it, there is no argument for it being factually superior or inferior. It is only preference. There is nothing stopping a forum link being created and posted to the list as an alternative right now. The result of that experiment would be the answer. On Wed, Feb 28, 201

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

On Wed, Feb 28, 2018 at 10:23:08PM +, Matt Arcidy wrote: > if Linux kernel can handle it, there is no argument for it being factually > superior or inferior. It is only preference. > > There is nothing stopping a forum link being created and posted to the list > as an alternative right now.

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

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

[Python-ideas] Upgrading python-ideas to MM3?

Hi folks, A number of smaller python.org mailing lists have been successfully migrated to the PSF's Mailman 3 infrastructure, for example, the core-workflow mailing list: https://mail.python.org/mm3/archives/list/[email protected]/ The biggest practical gain from the upgrade is to allow fo

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 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] Upgrading python-ideas to MM3?

Besides the login issues (or non-issues), assuming best case scenario, would the migration be seamless from my inbox’s point of view? Would I have to re-subscribe? From: Python-ideas [mailto:[email protected]] On Behalf Of Nick Coghlan Sent: Thursday,

Re: [Python-ideas] Upgrading python-ideas to MM3?

01.03.18 07:28, Nick Coghlan пише: A number of smaller python.org mailing lists have been successfully migrated to the PSF's Mailman 3 infrastructure, for example, the core-workflow mailing list: https://mail.python.org/mm3/archives/list/[email protected]/ The bigge

Re: [Python-ideas] Upgrading python-ideas to MM3?

On 1 March 2018 at 17:19, Alex Walters wrote: > Besides the login issues (or non-issues), assuming best case scenario, > would the migration be seamless from my inbox’s point of view? Would I > have to re-subscribe? > Assuming all goes well (which it did for both core-mentorship and core-workfl

Re: [Python-ideas] Upgrading python-ideas to MM3?

On 1 March 2018 at 17:33, Serhiy Storchaka wrote: > 01.03.18 07:28, Nick Coghlan пише: > >> A number of smaller python.org mailing lists have >> been successfully migrated to the PSF's Mailman 3 infrastructure, for >> example, the core-workflow mailing list: https://mail.pytho