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@gmail.com> a écrit : On Thu, Mar 1, 2018 at 8:38 AM, Robert Vanden Eynde <robertve92@gmail.com> wrote:
Le 28 févr. 2018 11:43, "Chris Angelico" <rosuav@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/