Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)
That should probably be its own thread
From: Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon.com@python.org] On Behalf Of Robert Vanden Eynde
Sent: Wednesday, February 28, 2018 4:48 PM
Cc: python-ideas
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/2b4ca20963a24cf5faac054226857ea9705471...) : """ 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. """
By "thread" you mean like "email thread" ?
Meaning when I want to talk about multiple stuffs, I send multiple mails
with different "Subject Lines" ? I have like multiple issues :
- Base Syntax (multiple choice, list pros and cons)
- Extended Syntax (what about parenthesis, and multiple assignement, and
while, and list comprehension)
- Scoping
- Use cases (list multiple ones)
- Cons (list multiple ones and solution).
It looks like, because it's a PEP, people think of it like "I should say +1
or −1 until something else is created" :/
2018-02-28 22:54 GMT+01:00 Alex Walters
That should probably be its own thread
*From:* Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon.com@ python.org] *On Behalf Of *Robert Vanden Eynde *Sent:* Wednesday, February 28, 2018 4:48 PM *Cc:* python-ideas
*Subject:* Re: [Python-ideas] PEP 572: Statement-Local Name Bindings 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
: Le 28 févr. 2018 11:43, "Chris Angelico"
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.
"""
The topic has been discussed to death with all possible pros and cons. I've published my personal collection of pros and cons at http://phdru.name/Software/mail-vs-web.html And my personal bottom line is: I still prefer mailing lists but I know their advantages and disadvantages and I've invested a lot of resources to learn and configure my tools. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
"This page was intentionally left blank."
-----Original Message----- From: Python-ideas [mailto:python-ideas-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Oleg Broytman Sent: Wednesday, February 28, 2018 5:12 PM To: python-ideas@python.org Subject: Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)
The topic has been discussed to death with all possible pros and cons. I've published my personal collection of pros and cons at http://phdru.name/Software/mail-vs-web.html
And my personal bottom line is: I still prefer mailing lists but I know their advantages and disadvantages and I've invested a lot of resources to learn and configure my tools.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Oops, sorry, fixed.
On Wed, Feb 28, 2018 at 05:18:43PM -0500, Alex Walters
"This page was intentionally left blank."
-----Original Message----- From: Python-ideas [mailto:python-ideas-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Oleg Broytman Sent: Wednesday, February 28, 2018 5:12 PM To: python-ideas@python.org Subject: Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)
The topic has been discussed to death with all possible pros and cons. I've published my personal collection of pros and cons at http://phdru.name/Software/mail-vs-web.html
And my personal bottom line is: I still prefer mailing lists but I know their advantages and disadvantages and I've invested a lot of resources to learn and configure my tools.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
if Linux kernel can handle it, there is no argument for it being factually
superior or inferior. It is only preference.
There is nothing stopping a forum link being created and posted to the list
as an alternative right now.
The result of that experiment would be the answer.
On Wed, Feb 28, 2018, 14:14 Oleg Broytman
The topic has been discussed to death with all possible pros and cons. I've published my personal collection of pros and cons at http://phdru.name/Software/mail-vs-web.html
And my personal bottom line is: I still prefer mailing lists but I know their advantages and disadvantages and I've invested a lot of resources to learn and configure my tools.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Feb 28, 2018 at 10:23:08PM +0000, Matt Arcidy
if Linux kernel can handle it, there is no argument for it being factually superior or inferior. It is only preference.
There is nothing stopping a forum link being created and posted to the list as an alternative right now.
The result of that experiment would be the answer.
The problem with the approach is division inside community and miscommunication between subgroup. One medium (currently it's the mailing list) is more preferable. Once an idea is discussed using the preferred medium and code is created the other groups will feel they have been singled out and their ideas were ignored. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
The best we can do here is move to MM3, as is being discussed in another
thread.
On Wed, Feb 28, 2018 at 2:39 PM, Oleg Broytman
if Linux kernel can handle it, there is no argument for it being factually superior or inferior. It is only preference.
There is nothing stopping a forum link being created and posted to the
On Wed, Feb 28, 2018 at 10:23:08PM +0000, Matt Arcidy
wrote: list as an alternative right now.
The result of that experiment would be the answer.
The problem with the approach is division inside community and miscommunication between subgroup.
One medium (currently it's the mailing list) is more preferable. Once an idea is discussed using the preferred medium and code is created the other groups will feel they have been singled out and their ideas were ignored.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
participants (5)
-
Alex Walters
-
Guido van Rossum
-
Matt Arcidy
-
Oleg Broytman
-
Robert Vanden Eynde