[Python-ideas] Fwd: Null coalescing operator
MRAB
python at mrabarnett.plus.com
Tue Sep 13 14:24:17 EDT 2016
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.cliffe at 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.
More information about the Python-ideas
mailing list