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

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" <> a écrit :
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", 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
> (
> :
> """
> 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.

Python-ideas mailing list
Code of Conduct: