[Python-ideas] PEP 572: Statement-Local Name Bindings
Robert Vanden Eynde
robertve92 at gmail.com
Fri Mar 2 10:18:39 EST 2018
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 [ x+1 ]]
→ [y+2 for x in range(5) with y = x+1]
2) Any expression :
print(y + 2 with x = 2)
So, IF the syntax is allowed in *both* cases, then yes, the "any expression
case" would introduced a "There is not one obvious way to do it".
Now introducing *scoping*, the "any expression case" can become handy
because it would create local variables in parenthesis :
x = 2
print([y, x/y] with y = x + 2)
print(y) # NameError
It would structure expressions and would be in the same idea as PEP 3150
<https://www.python.org/dev/peps/pep-3150/> but with a less drastic syntax
and more simple use case.
Maybe both cases are completely different and your we would have 3
1) "EXPR as NAME" → to easily reuse an expression used multiple times in an
2) "EXPR with NAME = EXPR" (any expression) → same purpose, different syntax
3) "[EXPR for x in ITERABLE with NAME = EXPR] → to allow reuse of an
expression in a list comprehension.
Maybe the only use cases are in list comprehensions and would be an
improvement to the for y in [ f(x) ] not obvious syntax (that was my
original thought weeks ago and in June of last year).
Your syntax gives a proof of concept implementation
The AnyExpression case had a proof of concept in thektulu (branch
Should we create "yet another pep" for each of this use cases or is it part
of a big same idea ?
Le 28 févr. 2018 22:53, "Chris Angelico" <rosuav at gmail.com> a écrit :
On Thu, Mar 1, 2018 at 8:38 AM, Robert Vanden Eynde
<robertve92 at gmail.com> wrote:
> Le 28 févr. 2018 11:43, "Chris Angelico" <rosuav at gmail.com> 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", but also to
> include temporary variables to better understand the code.
> Same for functions, you could inline functions when used only once, but
> introduce them for clarity no ?
Sure, but if you're creating temporaries for clarity, you should
probably make them regular variables, not statement-local ones. If
you're going to use something only once and you don't want to break it
out into a separate statement, just use a comment.
> a = v ** 2 / R # the acceleration in a circular motion
> f = m * a # law of Newton
> could be written as
> f = m * (v ** 2 / R) # compute the force, trivial
> But having temporary variables help a lot to understand the code,
> why would we create temporary variables ?
> I can give you an example where you do a process and each time the
> is used only one.
Neither of your examples needs SLNBs.
>> Scoping is a fundamental part of both my proposal and the others I've
>> seen here. (BTW, that would be a NameError, not a SyntaxError; it's
>> perfectly legal to ask for the name 'y', it just hasn't been given any
>> value.) By my definition, the variable is locked to the statement that
>> created it, even if that's a compound statement. By the definition of
>> a "(expr given var = expr)" proposal, it would be locked to that
>> single expression.
> Confer the discussion on scoping on github
> In the current implementation it looks like it is like a regular
> (function local then).
> Therefore in the expression usage, the usefulness would be debatable (just
> assign before).
> But in a list comprehension after the for (as I mentioned in my mail),
> when used as a replacement for for y in [ x + 1 ] this would make sense.
> But I think that it would be much better to have a local scope, in the
> parenthesis. So that print(y+2 where y = x + 1) wouldn't leak y. And when
> there are no parenthesis like in a = y+2 where y = x+1, it would imply
> giving the same effect as a = (y+2 where y = x+1). Moreover, it would
> naturally shadow variables in the outermost scope.
So the question is: what is the benefit of the local name 'y'? In any
non-trivial example, it's not going to fit in a single line, so you
have to either wrap it as a single expression (one that's been made
larger by the "where" clause at the end), or break it out into a real
variable as a separate assignment.
Python-ideas mailing list
Python-ideas at python.org
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas