On 5/12/19 1:03 pm, David Mertz wrote:
Actually, I found it's rejected PEP:
https://www.python.org/dev/peps/pep-3136/.
It looks like the first of several ideas there matches my ad hoc
syntax. It *was* 2007, in distant pre-walrus memory. But I'm not sure
the SC would revisit Guido's ruling.
Whoops, didn't realise my remark let this discussion continue in a
different direction :-)
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). I like systems that don't fail :-).
Various key elements are covered, such as readability and
predictability. In other words, everything in that language is geared
towards that, including named loops. But I digress.
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 :-)
Where it comes to the far reaching effects of such a change I'll have to
respectfully bow my head and follow the lead of those who know.
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. Compilers (or in case of Python:
smart IDEs) can then help find errors in logic that otherwise would only
surface at runtime. Don't get me wrong though... I've never needed a
goto since I stopped using Basic a few centuries ago. It's easy to
avoid. But multiple returns should, following the same logic, ideally
not be supported by the language as code using those will be less clear
than code that doesn't.
cheers,
Jan
On Wed, Dec 4, 2019, 6:45 PM Andrew Barnert via Python-ideas
<python-ideas@python.org <mailto:python-ideas@python.org>> wrote:
On Dec 4, 2019, at 12:14, Mike Miller <python-id...@mgmiller.net
<mailto:python-id...@mgmiller.net>> wrote:
>
>
>> On 2019-12-04 11:05, David Mertz wrote:
>> I've often wanted named loops. I know approaches to this have
been proposed many times, and they all have their own warts. E.g.
an ad hoc pseudo code that may or may not match any previous proposal:
>> for x in stuff as outer:
>> for y in other_stuff as inner:
>> ...
>> if cond:
>> break outer
>> But we all manage without it.
>
> +1 Nice, find myself with that problem about once a year and it
is annoying to code around
If you want to change this from an aside to a real proposal, it’s
probably worth starting a new thread (and providing a real-life
use case—if we all run into it once a year, many people probably
won’t remember exactly what it looked like when they last ran into
it, and how much their workaround bothered them).
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
<mailto:python-ideas@python.org>
To unsubscribe send an email to python-ideas-le...@python.org
<mailto: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/JUGJIGEMT7KZ345VYM4CWJD2XWPKPQEH/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/TU7ABLRE6M57TNQ2PQLBXSHAVCJJEZAU/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/5UEYIDXU2YE54ZREO4O6EOON5N5GPBJ5/
Code of Conduct: http://python.org/psf/codeofconduct/
