[Python-Dev] PEP 463: Exception-catching expressions

Nick Coghlan ncoghlan at gmail.com
Fri Feb 21 15:28:01 CET 2014


On 22 February 2014 00:03, Eli Bendersky <eliben at gmail.com> wrote:
> On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> PEP: 463
>> Title: Exception-catching expressions
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Chris Angelico <rosuav at gmail.com>
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 15-Feb-2014
>> Python-Version: 3.5
>> Post-History: 16-Feb-2014, 21-Feb-2014
>>
>>
>> Abstract
>> ========
>>
>> Just as PEP 308 introduced a means of value-based conditions in an
>> expression, this system allows exception-based conditions to be used
>> as part of an expression.
>
>
>
> Chris, while I also commend you for the comprehensive PEP, I'm -1 on the
> proposal, for two main reasons:
>
> 1. Many proposals suggest new syntax to gain some succinctness. Each has to
> be judged for its own merits, and in this case IMHO the cons eclipse the
> pros. I don't think this will save a lot of code in a typical
> well-structured program - maybe a few lines out of hundreds. On the other
> hand, it adds yet another syntax to remember and understand, which is not
> the Pythonic way.
>
> 2. Worse, this idea subverts exceptions to control flow, which is not only
> un-Pythonic but also against the accepted practices of programming in
> general. Here, the comparison to PEP 308 is misguided. PEP 308, whatever
> syntax it adds, still remains within the domain of normal control flow. PEP
> 463, OTOH, makes it deliberately easy to make exceptions part of
> non-exceptional code, encouraging very bad programming practices.

Neither of these objections addresses the problems with the status quo, though:

- the status quo encourages overbroad exception handling (as
illustrated by examples in the PEP)
- the status quo encourages an ad hoc approach to hiding exception
handling inside functions

PEP 308 was accepted primarily because the and/or hack was a bug
magnet. The status quo for exception handling is both a bug magnet
(due to overbroad exception handlers), and a cause of creeping
complexity in API design (as more and more APIs, both in the standard
library and elsewhere, acquire ways to request implicit exception
handling).

That's why the comparison to PEP 308 is appropriate: it's less about
making the language better directly, and more about deciding the
consequences of not having it are no longer acceptable.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list