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

[Robert Vanden Eynde]

We are currently like a dozen of people talking about multiple sections of
a single subject.

Isn't it easier to talk on a forum?
*Am I the only one* who thinks mailing list isn't easy when lots of people
talking about multiple subjects?

Of course we would put the link in the mailing list so that everyone can
join.

A forum (or just few "issues" thread on github) is where we could have
different thread in parallel, in my messages I end up with like *10
comments not all related*, in a forum we could talk about everything and it
would still be organized by subjects.

Also, it's more interactive than email on a global list, people can talk to
each other in parallel, if I want to answer about a mail that was 10 mail
ago, it gets quickly messy.

We could all discuss on a gist or some "Issues" thread on GitHub.

2018-02-28 22:38 GMT+01:00 Robert Vanden Eynde <robertve92 at gmail.com>:

> 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/e095cce6/attachment-0001.html>