Please, a survey:
My methods are not aggressive, they are intended to be merely philosophical.
Taking you at your word…
When they apply, match statements are like async/await: they take things that were technically already possible, but give them a massively more concise syntax that expresses the code’s intent far more clearly.
The fact users that aren’t writing the kind of code where those syntactic features are beneficial can pretty much ignore their existence is a feature rather than a problem (the fear that wouldn’t be the case was a genuine argument against adding the pattern matching constructs).
By contrast, do-while syntax ideas are instead playing in a space more like that of f-strings: like string formatting, conditional loops are likely to appear in almost all Python code at any level of sophistication. Since they won’t be avoidable, they would need to be approaching f-string levels of improvement in expressiveness to justify a change, and that’s a challenging bar to meet.
Is it possible to make a build with ‘do until’ right now without much effort? Just let me see that.
i_do = False
condition = True
while i_do != True or not condition:
try:
if i_do == False:
print("This is the first iteration")
finally:
i_do = True
Clear syntax proposed like ‘yield’ or ‘return’. After considering the suggestions, I think it’s best to declare the variable at the end.
do:
print("This iteration always runs in do until loop")
condition = False
until condition
would be consistent with python syntax logic. Should throw an error ‘if or if’ until is not specified, it is mandatory.
and we can add its while mode:
do:
print("This iteration always runs in do while loop")
condition = False
while condition
isn’t it beautiful?
When checking the implementation in the syntax we should always check at the end of the block if ‘until’ or ‘while’ and its condition are present.
Did you really fail to follow this entire discussion you yourself started?
while True:
print("This iteration always runs in do until loop")
condition = False
if condition: break
does exactly what you want, as has been discussed multiple times. Your suggestion is a tiny amount of syntax sugar for something that can already be expressed easily, it just doesn’t read quite as well.
Sorry for veering off topic. But which library or Python build did you use for this, John? Is there more progress towards adding macros than PEP 638 and macropy3?
While I agree that the OP is not doing a great job at providing compelling examples and could stand to take some of the feedback given in this thread to heart I also think it’s disingenuous to pretend the two examples you provided are actually equivalent. They may give the same result, but they don’t produce the same code-flow and it’s easy to introduce bugs that way once the code for the iteration has to change.
Once you introduce things like a continue statement in your loop, you no longer have the luxury of using a transformation this simple and are forced to either introduce an additional level of indentation for a try/finally or with context manager or you need to transform your loop condition in a way that it’s always False in the first iteration and always an iteration behind afterwards[1].
That being said, I still think the current ways to achieve an equivalent or similar code flow are sufficient and you will need a lot more than “it would simplify some code” to convince people otherwise. Python is not like C, where having the one extra superfluous conditional jump would have any measurable impact.
or you can do the first/last iteration outside the loop ↩︎
IT’S NOT. IMO “pattern matching” is one of the most powerful features of Python. You don’t use the match statement because you don’t know enough about it.
Franco, I suggest to drop this proposal, multiple people have tried to explain this (not coincidentally the most liked replies):
If you choose to ignore the feedback, we might need to close this topic.
I think it fair to point out that some features that get into a language over time are different than others in various ways.
Specifically, if you look at the early years when @guido and others had the first ideas for a language based on valuing some ideas over others, there was already a well-established group of ideas in languages that did use some variant of the feature being discussed (and I think at this point rejected.) It was deliberately not included as the methods chosen covered so many situations, as @Rosuav mentioned.
In particular, many real-world problems may very naturally be resolved as different exit or continue points from a loop as soon as it is determined you know what to do with the current item.
On the other hand, various ideas have bubbled up more recently and were not seriously looked at decades ago. Some of the more interesting pattern matching ideas are way more useful than endless nested if statements and can express ideas more clearly. There are languages that actually mostly use such constructs instead of explicit if statements.
I think many newer programmers will use such features more but for now, existing programmers may adopt them slower, and like any new features, there is inertia as older versions of python will fail to do the right thing with such code.
But the argument that lots of people must do what you want because they did something else you don’t care about, is baseless.
I don’t want to use break.
This code is equivalent to the do-while syntax:
condition = True
while condition:
print(condition)
condition = False
For example, this code:
do len(to_do) == 0:
tasks_done.append(to_do.pop(0))
…is equivalent to:
condition = True
while condition:
tasks_done.append(to_do.pop(0))
condition = len(to_do)
Both versions will raise IndexError: pop from empty list if to_do is empty.
It’s much safer to use:
There were old discussions about adding a do/while construct but no syntax had a good fit with the rest of the language. Your example puts do <cond>: at the top even though the condition is first evaluated at the bottom. But Python aims to have the visual appearance of code match its semantics (hences the colons and indentation). The only exception to that rule is yield which has spooky-action-at-a-distance changing what a function call does. That mistake was not repeated with await which requires async def to announce the semantics at the outset.