On 2016-09-13 16:27, Rob Cliffe wrote:
On 13/09/2016 12:37, Nick Coghlan wrote:
On 13 September 2016 at 21:15, Rob Cliffe <rob.cli...@btinternet.com> wrote:
On 13/09/2016 04:43, Guido van Rossum wrote:
Yeah, that's exactly my point. PEP 463 gives you a shorter way to
catch an exception, so it gives you less motivation to find a way to
write your code (or define your API) that doesn't involve catching
exceptions. But APIs involving exceptions are often inferior to APIs
that don't require exception catching. (Yes, I am aware of __next__()
raising StopIteration -- but that API design usually doesn't require
you to catch it.)
You surprise me. I thought LBYL and EAFP were both approved Python idioms,
in some cases one being better, in some cases another, choice to be made on
the merits of each case (or the author's preference). I certainly use both
(and sometimes time both to see which is faster).
Now it sounds as if you're trying to impose a style guide on the world by
discouraging the EAFP. And wasn't the discussion general, not about APIs
specifically?
Which is preferable depends greatly on context of use, which is why
you'll find a lot of Python APIs offer both forms
My point exactly. Random832 echoes my thoughts:
"Guido's argument here seems to be that exception-based EAFP is not
pythonic."
[snip]
I think the point is that exceptions are for, well, exceptional
processing, not normal processing.
Code should be written on the assumption that everything works normally,
e.g. division always returns a result.
_Occasionally_ division will fail, such as attempting to divide by zero,
but that should be uncommon.
If something pretty much always succeeds, use an exception for failure,
but if it sometimes succeeds and sometimes fails, check explicitly for
success or failure.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
