<div dir="auto"><div><div style="font-family:sans-serif;font-size:12.8px" dir="auto"><div><div><div><div><div><div><div>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).</div><div dir="auto"><span style="font-size:12.8px"><br></span></div><div dir="auto"><span style="font-size:12.8px">That's what I said on github, there are two different use cases : </span><b style="font-size:12.8px">ListComp</b><span style="font-size:12.8px"> Vs </span><b style="font-size:12.8px">AnyExpressions</b><span style="font-size:12.8px"> :</span></div><div dir="auto"><br></div>1) List comprehension :<br></div>[y+2 for x in range(5) for y in [ x+1 ]]<br>→ [y+2 for x in range(5) with y = x+1]<br><br></div>2) Any expression :<br></div><div>print(y + 2 with x = 2)<br></div><div><br></div>So, IF the syntax is allowed in <b>both</b> cases, then yes, the "any expression case" would introduced a "There is not one obvious way to do it".<br><br></div>Now introducing <b>scoping</b>, the "any expression case" can become handy because it would create local variables in parenthesis :<span style="font-family:monospace,monospace"><br><br></span></div><div><span style="font-family:monospace,monospace">x = 2<br>print([y, x/y] with y = x + 2)<br></span></div><div><span style="font-family:monospace,monospace">print(y) # NameError</span><br></div><div><br></div><div>It would structure expressions and would be in the same idea as <a href="https://www.python.org/dev/peps/pep-3150/" style="text-decoration-line:none;color:rgb(66,133,244)">PEP 3150</a> but with a less drastic syntax and more simple use case.<br><br></div>Maybe both cases are completely different and your we would have 3 proposals :<br></div>1) "EXPR as NAME" → to easily reuse an expression used multiple times in an expression.<br></div><span style="font-family:sans-serif;font-size:12.8px">2) "EXPR with NAME = EXPR" (any expression) → same purpose, different syntax</span><br style="font-family:sans-serif;font-size:12.8px"><div style="font-family:sans-serif;font-size:12.8px" dir="auto">3) "[EXPR for x in ITERABLE with NAME = EXPR] → to allow reuse of an expression in a list comprehension.<br><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">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).<br><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">Your syntax gives a proof of concept implementation<br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">The AnyExpression case had a proof of concept in <a href="https://github.com/thektulu/cpython/tree/where-expr" style="text-decoration-line:none;color:rgb(66,133,244)">thektulu (branch where-expr)</a><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto"><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">Should we create "yet another pep" for each of this use cases or is it part of a big same idea ?<br><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">Cheers,<br><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">Robert</div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 28 févr. 2018 22:53, "Chris Angelico" <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Thu, Mar 1, 2018 at 8:38 AM, Robert Vanden Eynde<br>
<<a href="mailto:robertve92@gmail.com">robertve92@gmail.com</a>> wrote:<br>
> Le 28 févr. 2018 11:43, "Chris Angelico" <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> a écrit :<br>
</div><div class="quoted-text">>> If you aren't using the variable multiple times, there's no point<br>
>> giving it a name. Unless I'm missing something here?<br>
><br>
> Yes, variables are not there "just because we reuse them", but also to<br>
> include temporary variables to better understand the code.<br>
> Same for functions, you could inline functions when used only once, but you<br>
> introduce them for clarity no ?<br>
<br>
</div>Sure, but if you're creating temporaries for clarity, you should<br>
probably make them regular variables, not statement-local ones. If<br>
you're going to use something only once and you don't want to break it<br>
out into a separate statement, just use a comment.<br>
<div class="quoted-text"><br>
><br>
> ```<br>
> a = v ** 2 / R # the acceleration in a circular motion<br>
> f = m * a # law of Newton<br>
> ```<br>
><br>
> could be written as<br>
><br>
> ```<br>
> f = m * (v ** 2 / R) # compute the force, trivial<br>
> ```<br>
><br>
> But having temporary variables help a lot to understand the code, otherwise<br>
> why would we create temporary variables ?<br>
> I can give you an example where you do a process and each time the variable<br>
> is used only one.<br>
<br>
</div>Neither of your examples needs SLNBs.<br>
<div class="quoted-text"><br>
>> Scoping is a fundamental part of both my proposal and the others I've<br>
>> seen here. (BTW, that would be a NameError, not a SyntaxError; it's<br>
>> perfectly legal to ask for the name 'y', it just hasn't been given any<br>
>> value.) By my definition, the variable is locked to the statement that<br>
>> created it, even if that's a compound statement. By the definition of<br>
>> a "(expr given var = expr)" proposal, it would be locked to that<br>
>> single expression.<br>
><br>
> Confer the discussion on scoping on github<br>
> (<a href="https://github.com/python/peps/commit/2b4ca20963a24cf5faac054226857ea9705471e5" rel="noreferrer" target="_blank">https://github.com/python/<wbr>peps/commit/<wbr>2b4ca20963a24cf5faac054226857e<wbr>a9705471e5</a>)<br>
> :<br>
><br>
> """<br>
> In the current implementation it looks like it is like a regular assignment<br>
> (function local then).<br>
><br>
> Therefore in the expression usage, the usefulness would be debatable (just<br>
> assign before).<br>
><br>
> But in a list comprehension after the for (as I mentioned in my mail), aka.<br>
> when used as a replacement for for y in [ x + 1 ] this would make sense.<br>
><br>
> But I think that it would be much better to have a local scope, in the<br>
> parenthesis. So that print(y+2 where y = x + 1) wouldn't leak y. And when<br>
> there are no parenthesis like in a = y+2 where y = x+1, it would imply one,<br>
> giving the same effect as a = (y+2 where y = x+1). Moreover, it would<br>
> naturally shadow variables in the outermost scope.<br>
<br>
</div>So the question is: what is the benefit of the local name 'y'? In any<br>
non-trivial example, it's not going to fit in a single line, so you<br>
have to either wrap it as a single expression (one that's been made<br>
larger by the "where" clause at the end), or break it out into a real<br>
variable as a separate assignment.<br>
<div class="elided-text"><br>
ChrisA<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></blockquote></div><br></div></div></div>