Greetings list,
I was wondering if adding the When keyword is a good idea. Normally every when is theoretically an if as you can't be sure if the event will 100% come to pass.
if x == 5: ... else: ...
However, we use the when keyword in normal language. When you reach home, phone me. When you pass this avenue, turn right etc. Using it in programming might convey the intent of the programmer.
when x == 5: ... else: ...
which still sells the idea of maybe if but hints away the expectation of the author.
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club http://www.pythonmembers.club/ | github https://github.com/Abdur-rahmaanJ Mauritius
This would break any code that uses “when” as a variable name.
https://github.com/search?l=Python&q=when&type=Code
On Sun, Dec 29, 2019 at 11:26 AM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:
Greetings list,
I was wondering if adding the When keyword is a good idea. Normally every when is theoretically an if as you can't be sure if the event will 100% come to pass.
if x == 5: ... else: ...
However, we use the when keyword in normal language. When you reach home, phone me. When you pass this avenue, turn right etc. Using it in programming might convey the intent of the programmer.
when x == 5: ... else: ...
which still sells the idea of maybe if but hints away the expectation of the author.
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club http://www.pythonmembers.club/ | github https://github.com/Abdur-rahmaanJ Mauritius _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUS... Code of Conduct: http://python.org/psf/codeofconduct/
Adding a new keyword automatically assumes breaking code.
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club http://www.pythonmembers.club/ | github https://github.com/Abdur-rahmaanJ Mauritius
On Sun, Dec 29, 2019 at 10:43 PM Nathan nathan.goldbaum@gmail.com wrote:
This would break any code that uses “when” as a variable name.
https://github.com/search?l=Python&q=when&type=Code
On Sun, Dec 29, 2019 at 11:26 AM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:
Greetings list,
I was wondering if adding the When keyword is a good idea. Normally every when is theoretically an if as you can't be sure if the event will 100% come to pass.
if x == 5: ... else: ...
However, we use the when keyword in normal language. When you reach home, phone me. When you pass this avenue, turn right etc. Using it in programming might convey the intent of the programmer.
when x == 5: ... else: ...
which still sells the idea of maybe if but hints away the expectation of the author.
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club http://www.pythonmembers.club/ | github https://github.com/Abdur-rahmaanJ Mauritius _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUS... Code of Conduct: http://python.org/psf/codeofconduct/
New keywords breaking code is why any proposal for a new keyword has to have a really strong justification. There has to be a large benefit to balance the implied cost of breaking code.
Your proposal (if I understand it correctly) is that "when" would execute exactly like "if". That is not a large benefit.
Python also has a strong culture of not using two different names for the exact same thing.
I can understand the appeal of using a keyword that fits English usage more closely, but this trade-off isn't worth it.
--Ned.
On 12/29/19 1:45 PM, Abdur-Rahmaan Janhangeer wrote:
Adding a new keyword automatically assumes breaking code.
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club http://www.pythonmembers.club/ | github https://github.com/Abdur-rahmaanJ Mauritius
On Sun, Dec 29, 2019 at 10:43 PM Nathan <nathan.goldbaum@gmail.com mailto:nathan.goldbaum@gmail.com> wrote:
This would break any code that uses “when” as a variable name. https://github.com/search?l=Python&q=when&type=Code On Sun, Dec 29, 2019 at 11:26 AM Abdur-Rahmaan Janhangeer <arj.python@gmail.com <mailto:arj.python@gmail.com>> wrote: Greetings list, I was wondering if adding the When keyword is a good idea. Normally every when is theoretically an if as you can't be sure if the event will 100% come to pass. if x == 5: ... else: ... However, we use the when keyword in normal language. When you reach home, phone me. When you pass this avenue, turn right etc. Using it in programming might convey the intent of the programmer. when x == 5: ... else: ... which still sells the idea of maybe if but hints away the expectation of the author. Yours, Abdur-Rahmaan Janhangeer pythonmembers.club <http://www.pythonmembers.club/> | github <https://github.com/Abdur-rahmaanJ> Mauritius _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUSHPYTKLL65V6BUN4MMKKJOXCIKO/ Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZTZ3RH... Code of Conduct: http://python.org/psf/codeofconduct/
Hi,
Adding a new keyword will break many code because "when" would be a new reserved word, and may currently be used as a variable name. Also, "when" is not an equivalent of "if", it has a time-related connotation. If I see a "when" keyword in a code, I will think that the body will be executed later, when the expression will be true.
Regards,
Le dim. 29 déc. 2019 à 19:29, Abdur-Rahmaan Janhangeer arj.python@gmail.com a écrit :
Greetings list,
I was wondering if adding the When keyword is a good idea. Normally every when is theoretically an if as you can't be sure if the event will 100% come to pass.
if x == 5: ... else: ...
However, we use the when keyword in normal language. When you reach home, phone me. When you pass this avenue, turn right etc. Using it in programming might convey the intent of the programmer.
when x == 5: ... else: ...
which still sells the idea of maybe if but hints away the expectation of the author.
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club | github Mauritius _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3VOQUS... Code of Conduct: http://python.org/psf/codeofconduct/
Yours,
Abdur-Rahmaan Janhangeer pythonmembers.club http://www.pythonmembers.club/ | github https://github.com/Abdur-rahmaanJ Mauritius
On Sun, Dec 29, 2019 at 10:45 PM Antoine Rozo antoine.rozo@gmail.com wrote:
If I see a "when" keyword in a code, I will think that the body will be executed later, when the expression will be true.
Do you see an advantage having in such a case?
On Dec 29, 2019, at 10:57, Abdur-Rahmaan Janhangeer arj.python@gmail.com wrote:
On Sun, Dec 29, 2019 at 10:45 PM Antoine Rozo antoine.rozo@gmail.com wrote:
If I see a "when" keyword in a code, I will think that the body will be executed later, when the expression will be true.
Do you see an advantage having in such a case?
There are lots of advantages.
Imagine being able to do debugger-style watchpoints from within your code without having to run in a debugger. Whenever x becomes 5 on your live webserver, it logs a stack trace.
You could also use this to validate inputs in a GUI—people already do this today with Tkinter, which provides variables that can be hooked with callback functions, but syntactic support would eliminate a lot of the boilerplate.
You could even use it to add thread safety to single-threaded libraries from outside (when this becomes true, notify a condition variable…). I think I wrote a facetious post on my old Stupid Python Ideas blog on all the control flow statements Python is “missing” and included a when for this purpose.
I don’t think the advantage is anywhere near worth the cost. Being explicit about which variables are hooked, and where hooks are registered, as in Tkinter, aids readability a lot more than the extra boilerplate hurts it, and also allows the interpreter to be simpler and faster.
But that’s exactly why the question is never “could this be useful?” but “would this be useful enough to be worth the cost?”. And the same question comes up for your proposal. Sure, there are cases where when reads better than if. But that’s a small advantage. And the cost is that we have to implement it, we break backward compatibility, and everyone who reads Python code now has to keep 6 control flow statements in their head instead of 5.
On 12/29/19 3:13 PM, Andrew Barnert via Python-ideas wrote:
On Dec 29, 2019, at 10:57, Abdur-Rahmaan Janhangeer arj.python@gmail.com wrote:
On Sun, Dec 29, 2019 at 10:45 PM Antoine Rozo <antoine.rozo@gmail.com mailto:antoine.rozo@gmail.com> wrote:
If I see a "when" keyword in a code, I will think that the body will be executed later, when the expression will be true.Do you see an advantage having in such a case?
There are lots of advantages.
Imagine being able to do debugger-style watchpoints from within your code without having to run in a debugger. Whenever x becomes 5 on your live webserver, it logs a stack trace.
You could also use this to validate inputs in a GUI—people already do this today with Tkinter, which provides variables that can be hooked with callback functions, but syntactic support would eliminate a lot of the boilerplate.
You could even use it to add thread safety to single-threaded libraries from outside (when this becomes true, notify a condition variable…). I think I wrote a facetious post on my old Stupid Python Ideas blog on all the control flow statements Python is “missing” and included a when for this purpose.
I don’t think the advantage is anywhere near worth the cost. Being explicit about which variables are hooked, and where hooks are registered, as in Tkinter, aids readability a lot more than the extra boilerplate hurts it, and also allows the interpreter to be simpler and faster.
But that’s exactly why the question is never “could this be useful?” but “would this be useful enough to be worth the cost?”. And the same question comes up for your proposal. Sure, there are cases where when reads better than if. But that’s a small advantage. And the cost is that we have to implement it, we break backward compatibility, and everyone who reads Python code now has to keep 6 control flow statements in their head instead of 5.
AH, like the old conditional COME FROM statement that was proposed for FORTRAN decades ago.
The anti-pattern suggested to get away from structured code.
On Dec 29, 2019, at 12:52, Richard Damon Richard@damon-family.org wrote:
On 12/29/19 3:13 PM, Andrew Barnert via Python-ideas wrote:
On Dec 29, 2019, at 10:57, Abdur-Rahmaan Janhangeer arj.python@gmail.com wrote:
On Sun, Dec 29, 2019 at 10:45 PM Antoine Rozo <antoine.rozo@gmail.com mailto:antoine.rozo@gmail.com> wrote:
If I see a "when" keyword in a code, I will think that the body will be executed later, when the expression will be true.
Do you see an advantage having in such a case?
Imagine being able to do debugger-style watchpoints from within your code without having to run in a debugger. Whenever x becomes 5 on your live webserver, it logs a stack trace.
You could also use this to validate inputs in a GUI—people already do this today with Tkinter, which provides variables that can be hooked with callback functions, but syntactic support would eliminate a lot of the boilerplate.
You could even use it to add thread safety to single-threaded libraries from outside (when this becomes true, notify a condition variable…). I think I wrote a facetious post on my old Stupid Python Ideas blog on all the control flow statements Python is “missing” and included a when for this purpose.
I don’t think the advantage is anywhere near worth the cost.
AH, like the old conditional COME FROM statement that was proposed for FORTRAN decades ago.
The anti-pattern suggested to get away from structured code.
Yeah—and see INTERCAL (and especially the threaded dialect) to demonstrate both the fundamental usefulness and the fundamental unreadability of the feature. Of course for INTERCAL those are both advantages, rather than an advantage and a cost to be balanced. :)
participants (6)
-
Abdur-Rahmaan Janhangeer -
Andrew Barnert -
Antoine Rozo -
Nathan -
Ned Batchelder -
Richard Damon