[Python-ideas] Fwd: Null coalescing operator

Rob Cliffe rob.cliffe at btinternet.com
Tue Sep 13 11:27:44 EDT 2016



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]
> However, blindly catching *all* exceptions from a complex
> subexpression is rarely the right thing to do,
Of course.
>   so APIs that only offer
> "this may throw exceptions during normal operation under these
> circumstances" without a convenience wrapper that does the exception
> handling for you can end up being a pain to work with.
>
> PEP 463 makes those APIs less painful to deal with, but at the cost of
> encouraging overly broad exception handlers.
Why?  You can catch exactly the same (wide or narrow) range of 
exceptions in an exception-catching expression as you can in a 
try+except block.  Of course
     result = (myList[0] except Exception: MyDefault)
is poor code (presumably it should have been written "except 
IndexError"), but so is
     try:
         result = myList[0]
     except Exception:
         result = MyDefault
ISTM you're giving an exception-catching dog a bad name and hanging 
him.  Or have I missed something?

And sorry to repeat myself, but we seemed to be having a *general* 
discussion about null-coalescing operators, which moved on to PEP 463, 
then suddenly Guido is talking about APIs.  A lot of the time when I'm 
coding, I'm not writing an API, just a program to get a job done.  No 
doubt, exceptions should be discouraged *in APIs*, but that doesn't make 
exceptions, or EAFP, a bad idea per se.

I really don't mean this post to sound hostile, and I'm sorry if it 
comes across a bit that way.  I'm just surprised at what I'm hearing, 
and to be honest, I have a soft spot for PEP 463.
Best wishes
Rob Cliffe


More information about the Python-ideas mailing list