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

[Matt Arcidy]

-0 unless archived appropriately.  List is the standard for decades.  but I
guess things change and I get old.

On Wed, Feb 28, 2018, 13:49 Robert Vanden Eynde <robertve92 at gmail.com>
wrote:

> 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.
>> """
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180228/9596fa82/attachment-0001.html>