On Dec 4, 2019, at 17:55, Jan Bakuwel <[email protected]> wrote: > > > Just read Guido's reason for rejecting named loops, interesting. It seems we > have different ideas about what "code clarity" means and that's perfectly > fine of course. Beauty is in the eye of the beholder. To refer once again to > Ada (sorry), that language was explicitly designed taking core software > engineering principles and various issues with existing languages into > account to create "the perfect language" for systems that must not fail (if > we can help it)
Note that it was designed taking core software engineering principles of the 1970s and the distinct languages of the 1970s into account to create “the perfect Pascal”. A lot has changed in the nearly 40 years since the report was published. For just two examples: The notion of what a type system can do has been vastly extended, meaning that Haskell and Rust and Swift can prevent all kinds of errors that nobody believed could possibly be prevented in 1980. And advances in multithreading have opened a whole new class of problems that nobody could have even imagined, much less tried to solve, in 1980, so Go and Java have tools to verify lock-free behavior; Ada does not. > Regarding those named loops, I do get across that from time to time (not > every month) but don't think that it only occurs in complicated code. I also > don't see how it can be "abused". So far when I used it, it was the most > elegant way to leave an inner loop. If one can have nested loops then, I > think, one should be able to break or continue out of any of those loops > without having to resort to yet another single use function that has no other > purpose. Raising an exception is an obvious alternative but I've learned that > exceptions are expensive. If that's not the case in Python, I'll have to > unlearn that :-) Yes, you have to unlearn it. Exceptions are not that expensive in Python (and in a lot of other modern languages)—but even if they were, you’d still have to deal with the fact that Python uses them pervasively. Every for loop ends with an exception being thrown and caught, whether you like it or not. > Guido brings up the topic of using goto (bad) and return (good) in his > rejection. I've seen multiple returns in Python functions. I think that is a > bad idea; a goto would be better than multiple returns as it results in more > predictive behaviour and facilitates having only one clean "exit" point of > the function. I’ve never understood this idea. The dogma comes from C, where functions usually have to do a lot of explicit cleanup at the end, which means an early return complicates that cleanup, often in really messy ways that people get wrong all the time. So it makes sense for C. But most languages are not C. Even C++ programmers quickly figured out that this doesn’t even extend to their closely-related language as long as you use it properly. But other people keep trying to extend it to languages like Python where there’s not even a “if you use it properly” condition. Storing a value in an otherwise-unnecessary variable and then making sure you correctly break out of and/or skip over all of the remaining flow control to safely arrive at the end of a function is complicated. Returning early doesn’t have those problems. And if you don’t like early return, how could you possibly like labeled break? It’s a similar goto in disguise, it means every loop now has multiple clean exit points that you have to keep track of possibly buried deep down in the nesting, it means any explicit cleanup might get skipped accidentally… if none of that is a problem for labeled break, why is any of it a problem for early return? > Compilers (or in case of Python: smart IDEs) can then help find errors in > logic that otherwise would only surface at runtime. Why do early returns make that any harder? (Other than eliminating some of the sources of those logic errors in the first place, which doesn’t seem like a bad thing.) What’s an example of a logic error that a compiler could catch without early return but can’t catch with it? _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/UUULRHCCCSFQNSI76WXBR2FGWVVE3KQT/ Code of Conduct: http://python.org/psf/codeofconduct/
