Hi Andrew,
On 5/12/19 3:43 pm, Andrew Barnert wrote:
On Dec 4, 2019, at 17:55, Jan Bakuwel<jan.baku...@gmail.com> 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.
Does Python have tools to do that? I hit one of those snags a few weeks
ago. Today's Ada is not the 80-ies Ada either. Fact is, it's still used
for mission critical systems and for good reasons. Let me put it this
way: I doubt we'll see Python used in aircraft control systems, but will
happily stand corrected if I got that wrong. Ada wouldn't be used today
if it would be 40 years old technology.
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.
Sweet, thanks :-) Done.
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?
I agree it's a goto in disguise. But it does have merits in certain
cases, for example searching for something in nested data sets and once
found you're done.
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?
I think it's harder to understand how a function works if that function
has various ways it could end instead of just one. Maybe that's just me
thinking that is cleaner. What is clean is, to a certain extend, in the
eye of the beholder. An example of a logic error would be where a
variable is used before it's being assigned, which could be the case for
one of the returns but not for the other.
regards,
Jan
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/S5FFHZMEDX765QUR57RCZHMJDVUHQBY5/
Code of Conduct: http://python.org/psf/codeofconduct/
