Showing content from http://mail.python.org/pipermail/python-dev/attachments/20140221/fc44af6e/attachment.html below:
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 22 February 2014 00:03, Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
> On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
>><br>
>> PEP: 463<br>
>> Title: Exception-catching expressions<br>
>> Version: $Revision$<br>
>> Last-Modified: $Date$<br>
>> Author: Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>><br>
>> Status: Draft<br>
>> Type: Standards Track<br>
>> Content-Type: text/x-rst<br>
>> Created: 15-Feb-2014<br>
>> Python-Version: 3.5<br>
>> Post-History: 16-Feb-2014, 21-Feb-2014<br>
>><br>
>><br>
>> Abstract<br>
>> ========<br>
>><br>
>> Just as PEP 308 introduced a means of value-based conditions in an<br>
>> expression, this system allows exception-based conditions to be used<br>
>> as part of an expression.<br>
><br>
><br>
><br>
> Chris, while I also commend you for the comprehensive PEP, I'm -1 on the<br>
> proposal, for two main reasons:<br>
><br>
> 1. Many proposals suggest new syntax to gain some succinctness. Each has to<br>
> be judged for its own merits, and in this case IMHO the cons eclipse the<br>
> pros. I don't think this will save a lot of code in a typical<br>
> well-structured program - maybe a few lines out of hundreds. On the other<br>
> hand, it adds yet another syntax to remember and understand, which is not<br>
> the Pythonic way.<br>
><br>
> 2. Worse, this idea subverts exceptions to control flow, which is not only<br>
> un-Pythonic but also against the accepted practices of programming in<br>
> general. Here, the comparison to PEP 308 is misguided. PEP 308, whatever<br>
> syntax it adds, still remains within the domain of normal control flow. PEP<br>
> 463, OTOH, makes it deliberately easy to make exceptions part of<br>
> non-exceptional code, encouraging very bad programming practices.<br>
<br>
</div></div>Neither of these objections addresses the problems with the status quo, though:<br>
<br>
- the status quo encourages overbroad exception handling (as<br>
illustrated by examples in the PEP)<br>
- the status quo encourages an ad hoc approach to hiding exception<br>
handling inside functions<br></blockquote><div><br></div><div>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.<br>
<br></div><div>(*) 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.<br>
<br></div><div>This goes against anything I understand about how exceptions should and should not be used.<br><br>Eli<br></div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
PEP 308 was accepted primarily because the and/or hack was a bug<br>
magnet. The status quo for exception handling is both a bug magnet<br>
(due to overbroad exception handlers), and a cause of creeping<br>
complexity in API design (as more and more APIs, both in the standard<br>
library and elsewhere, acquire ways to request implicit exception<br>
handling).<br>
<br>
That's why the comparison to PEP 308 is appropriate: it's less about<br>
making the language better directly, and more about deciding the<br>
consequences of not having it are no longer acceptable.<br>
<div class="HOEnZb"><div class="h5"><br>
</div></div></blockquote></div><br></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4