How do you think about borowwing from Ruby unless and allowing a do-while, e.g.:
unless False:
print(„hello”)
do:
print(„hello”)
while True
Moving this to the help category as it’s not a specific idea that will lead to productive discussion or change. Review how other successful ideas and discussions are presented in the ideas category to see what level of work you need to put in first.
Please describe why is this not an idea.
For starters, you should show existing code that would be improved by these changes, and discuss if there are opportunities for new, better coding styles that are enabled by these changes.
Ultimately the decision is “are the benefits of adding this greater than the costs?”. So we need to see the benefits.
What would unless provide that if not does not?
So first composing same code again because code construct does not exist is simply not DRY.
Then „unless” is needed because of inverting logic on large boolean expressions.
Then „do-while” is better than „while” with local function being called above and inside the code construct because of the DRY rule.
One can call it code sugar easilly available.
I think you’re referring to the so-called “loop and a half” issue. See the rejected PEP 315. It’s rejection section says “Users of the language are advised to use the while-True form with an inner if-break when a do-while loop would have been appropriate.” If you’d like to revive that PEP, you’ll need to address that point.
As for “unless”, I don’t think it makes code any clearer, but of course opinions can vary.
2 Likes
Thanks for finding the PEP.
I would rather have normal identation for boolean expression calculation.
Sorry, I don’t know what that means, or what it’s in response to.
So the do and while statements are on identation level 0 but break in while-if-break is on level 2 and if is on level 1.
I was talking simply about those identation levels created with spaces or tabs.
My bad indentation*
But you can already invert logic with the not operator, so what does unless add beyond another way of doing things?
It is for complex boolean expressions. Expecting false is more natural than inverting some chained expression.
What is more natural is in the eye of the beholder, and adding a new keyword requires much more justification than “sometimes it save a not and I find that pleasing.”
So you want to input both not and () for complex expression? My argument iis less error and more flexibility in counting correct boolean expressions.
I’ve occasionally had expressions where a “not” just made them more confusing. In that case I just do:
if complex-expression:
pass
else:
Code I really want to run
I think that’s good enough.
5 Likes
TBH, I hope Python never becomes an experiment in exuberant design the way Perl did.
You should have a look at BCPL sometime. 