On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 22 February 2014 00:03, Eli Bendersky <eli...@gmail.com> wrote: > > On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico <ros...@gmail.com> > wrote: > >> > >> PEP: 463 > >> Title: Exception-catching expressions > >> Version: $Revision$ > >> Last-Modified: $Date$ > >> Author: Chris Angelico <ros...@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. > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com