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

[Robert Vanden Eynde]

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
proposals :
1) "EXPR as NAME" → to easily reuse an expression used multiple times in an
expression.
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
where-expr) <https://github.com/thektulu/cpython/tree/where-expr>

Should we create "yet another pep" for each of this use cases or is it part
of a big same idea ?

Cheers,

Robert


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
you
> 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,
otherwise
> why would we create temporary variables ?
> I can give you an example where you do a process and each time the
variable
> 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
> (https://github.com/python/peps/commit/2b4ca20963a24cf5faac054226857e
a9705471e5)
> :
>
> """
> In the current implementation it looks like it is like a regular
assignment
> (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),
aka.
> 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
one,
> 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.

ChrisA
_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180302/53f5c359/attachment.html>