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