Add a clarifying paragraph to PEP 0479, and another post-history date.
This commit is contained in:
parent
26898355d5
commit
e9a519ab78
16
pep-0479.txt
16
pep-0479.txt
|
@ -8,7 +8,7 @@ Type: Standards Track
|
|||
Content-Type: text/x-rst
|
||||
Created: 15-Nov-2014
|
||||
Python-Version: 3.5
|
||||
Post-History: 15-Nov-2014
|
||||
Post-History: 15-Nov-2014, 19-Nov-2014
|
||||
|
||||
|
||||
Abstract
|
||||
|
@ -179,6 +179,20 @@ at the time of writing only two responses have been received: one was
|
|||
in favor of changing list comprehensions to match generator
|
||||
expressions (!), the other was in favor of this PEP's main proposal.
|
||||
|
||||
The existing model has been compared to the perfectly-acceptable
|
||||
issues inherent to every other case where an exception has special
|
||||
meaning. For instance, an unexpected ``KeyError`` inside a
|
||||
``__getitem__`` method will be interpreted as failure, rather than
|
||||
permitted to bubble up. However, there is a difference. Dunder
|
||||
methods use ``return`` to indicate normality, and ``raise`` to signal
|
||||
abnormality; generators ``yield`` to indicate data, and ``return`` to
|
||||
signal the abnormal state. This makes explicitly raising
|
||||
``StopIteration`` entirely redundant, and potentially surprising. If
|
||||
other dunder methods had dedicated keywords to distinguish between
|
||||
their return paths, they too could turn unexpected exceptions into
|
||||
``RuntimeError``; the fact that they cannot should not preclude
|
||||
generators from doing so.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
|
Loading…
Reference in New Issue