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 <pyt...@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.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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
