On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 22 February 2014 00:03, Eli Bendersky <eliben@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> PEP: 463
>> Title: Exception-catching expressions
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Chris Angelico <rosuav@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

I think the PEP, and your reply, focuses too much on one single "status quo" situation, which is the dict.get-like usage. However, the PEP does not propose a narrow solution - it proposes a significant change in the way expressions may be written and exceptions may be caught, and thus opens a can of worms. Even if the status quo will be made better by it, and even this I'm not sure about (*), many many other possibilities of bad code open up.

(*) IMHO it's better to hide these exceptions inside well defined functions -- because dict.get tells me it's the normal code flow, not the exceptional code flow. On the other hand, the syntax proposed herein tells me - yeah it's the exceptional code flow, but let me merge it into the normal code flow for you.

This goes against anything I understand about how exceptions should and should not be used.



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

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.