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

[Eli Bendersky]

On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
>

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.

Eli




>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140221/fc44af6e/attachment.html>