[Python-ideas] Fwd: Null coalescing operator

[Brett Cannon]

This general API discussion is veering off-topic for the subject line. If
people would like to continue to discuss it then please start a new thread
(if you feel it impacts your view of a null-coalescing operator then please
discuss in the new thread and come back to this one).

On Tue, 13 Sep 2016 at 11:25 MRAB <python at mrabarnett.plus.com> wrote:

> 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.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160913/55564415/attachment.html>