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

[Robert Vanden Eynde]

Le 28 févr. 2018 11:43, "Chris Angelico" <rosuav at gmail.com> a écrit :

> It's still right-to-left, which is as bad as middle-outward once you
> combine it with normal left-to-right evaluation. Python has very
> little of this [..]

I agree [....]

>> 2) talking about the implementation of thektulu in the "where =" part.

> ?

In the Alternate Syntax, I was talking about adding a link to the thektulu
(branch where-expr) <https://github.com/thektulu/cpython/commits/where-expr>
implementation as a basis of proof of concept (as you did with the other
syntax).

>> 3) "C problem that an equals sign in an expression can now create a name
inding, rather than performing a comparison."

As you agreed, with the "ch with ch = getch()" syntax we won't accidentally
switch a "==" for a "=".

I agree this syntax :

```
while (ch with ch = getch()):
    ...
```

doesn't read very well, but in the same way as in C or Java while(ch =
getch()){} or worse ((ch = getch()) != null) syntax.
Your syntax "while (getch() as ch):" may have a less words, but is still
not clearer.

As we spoke on Github, having this syntax in a while is only useful if the
variable does leak.

>> 5) Any expression vs "post for" only

> I don't know what the benefit is here, but sure. As long as the
> grammar is unambiguous, I don't see any particular reason to reject
> this.

I would like to see a discussion of pros and cons, some might think like me
or disagree, that's a strong langage question.

> 6) with your syntax, how does the simple case work (y+2 with y = x+1) ?

What simple case? The case where you only use the variable once? I'd
write it like this:

(x + 1) + 2

>> The issue is not only about reusing variable.

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

```
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.

>> 8)
>>  (lambda y: [y, y])(x+1)
>> Vs
>> (lambda y: [y, y])(y=x+1)

Ewww. Remind me what the benefit is of writing the variable name that
many times? "Explicit" doesn't mean "utterly verbose".

Yep it's verbose, lambdas are verbose, that's why we created this PEP isn't
it :)

> 10) Chaining, in the case of the "with =", in thektulu, parenthesis were
> mandatory:
>
> print((z+3 with z = y+2) with y = x+2)
>
> What happens when the parenthesis are dropped ?
>
> print(z+3 with y = x+2 with z = y+2)
>
> Vs
>
> print(z+3 with y = x+2 with z = y+2)
>
> I prefer the first one be cause it's in the same order as the "post for"
>
> [z + 3 for y in [ x+2 ] for z in [ y+2 ]]

> With my proposal, the parens are simply mandatory. Extending this to
> make them optional can come later.

Indeed, but that's still questions that can be asked.

>> 11) Scoping, in the case of the "with =" syntax, I think the parenthesis
>> introduce a scope :
>>
>> print(y + (y+1 where y = 2))
>>
>> Would raise a SyntaxError, it's probably better for the variable beeing
>> local and not in the current function (that would be a mess).
>>
>> Remember that in list comp, the variable is not leaked :
>>
>> x = 5
>> stuff = [y+2 for y in [x+1]
>> print(y) # SyntaxError

> 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/2b4ca20963a24cf5faac054226857ea9705471e5)
:

"""
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.

This would imply while data where data = sock.read(): does not leak data
but as a comparison with C and Java, the syntax while((data = sock.read())
!= null) is really really ugly and confusing.
"""
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180228/ce7070e1/attachment.html>