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:
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:
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:
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 :
-- Antoine Rozo
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:
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 Dec 29, 2019, at 12:52, Richard Damon <Richard@damon-family.org> wrote:
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. :)
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:
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:
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:
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 :
-- Antoine Rozo
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:
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 Dec 29, 2019, at 12:52, Richard Damon <Richard@damon-family.org> wrote:
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