reject PEP 317, with summary from author

pep-0000.txt

@@ -116,7 +116,6 @@ Index by Category
  S   313  Adding Roman Numeral Literals to Python      Meyer
  S   314  Metadata for Python Software Packages v1.1   Kuchling
  S   315  Enhanced While Loop                          Carroll
- S   317  Eliminate Implicit Exception Instantiation   Taschuk
  S   318  Function/Method Decorator Syntax             Smith
  S   319  Python Synchronize/Asynchronize Block        Pelletier
  S   754  IEEE 754 Floating Point Special Values       Warnes
@@ -185,6 +184,7 @@ Index by Category
  SR  289  Generator Comprehensions                     Hettinger
  SR  295  Interpretation of multiline string constants Koltsov
  SD  316  Programming by Contract for Python           Way
+ SR  317  Eliminate Implicit Exception Instantiation   Taschuk
  SR  666  Reject Foolish Indentation                   Creighton
 
 
@@ -328,7 +328,7 @@ Numerical Index
  S   314  Metadata for Python Software Packages v1.1   Kuchling
  S   315  Enhanced While Loop                          Carroll
  SD  316  Programming by Contract for Python           Way
- S   317  Eliminate Implicit Exception Instantiation   Taschuk
+ SR  317  Eliminate Implicit Exception Instantiation   Taschuk
  S   318  Function/Method Decorator Syntax             Smith
  S   319  Python Synchronize/Asynchronize Block        Pelletier
  SR  666  Reject Foolish Indentation                   Creighton

pep-0317.txt

@@ -3,12 +3,12 @@ Title: Eliminate Implicit Exception Instantiation
 Version: $Revision$
 Last-Modified: $Date$
 Author: Steven Taschuk <staschuk@telusplanet.net>
-Status: Draft
+Status: Rejected
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 06-May-2003
 Python-Version: 2.4
-Post-History:
+Post-History: 09-Jun-2003
 
 
 Abstract
@@ -312,6 +312,121 @@ cannot be made impossible short of issuing at compile-time a warning
 for every ``raise`` statement.
 
 
+Rejection
+=========
+
+If this PEP were accepted, nearly all existing Python code would need
+to be reviewed and probably revised; even if all the above arguments
+in favour of explicit instantiation are accepted, the improvement in
+clarity is too minor to justify the cost of doing the revision and the
+risk of new bugs introduced thereby.
+
+This proposal has therefore been rejected [6]_.
+
+Note that string exceptions are slated for removal independently of
+this proposal; what is rejected is the removal of implicit exception
+instantiation.
+
+
+Summary of Discussion
+=====================
+
+A small minority of respondents were in favour of the proposal, but
+the dominant response was that any such migration would be costly
+out of proportion to the putative benefit.  As noted above, this
+point is sufficient in itself to reject the PEP.
+
+
+New-Style Exceptions
+--------------------
+
+Implicit instantiation might conflict with future plans to allow
+instances of new-style classes to be used as exceptions.  In order to
+decide whether to instantiate implicitly, the ``raise`` machinery must
+determine whether the first argument is a class or an instance -- but
+with new-style classes there is no clear and strong distinction.
+
+Under this proposal, the problem would be avoided because the
+exception would already have been instantiated.  However, there are
+two plausible alternative solutions:
+
+1. Require exception types to be subclasses of ``Exception``, and
+   instantiate implicitly if and only if ::
+
+        issubclass(firstarg, Exception)
+
+2. Instantiate implicitly if and only if ::
+
+        isinstance(firstarg, type)
+
+Thus eliminating implicit instantiation entirely is not necessary to
+solve this problem.
+
+
+Ugliness of Explicit Instantiation
+----------------------------------
+
+Some respondents felt that the explicitly instantiating syntax is
+uglier, especially in cases when no arguments are supplied to the
+exception constructor::
+
+    raise TypeError()
+
+The problem is particularly acute when the exception instance itself
+is not of interest, that is, when the only relevant point is the
+exception type::
+
+    try:
+        # ... deeply nested search loop ...
+            raise Found
+    except Found:
+        # ...
+
+In such cases the symmetry between ``raise`` and ``except`` can be
+more expressive of the intent of the code.
+
+Guido opined that the implicitly instantiating syntax is "a tad
+prettier" even for cases with a single argument, since it has less
+punctuation.
+
+
+Performance Penalty of Warnings
+-------------------------------
+
+Experience with deprecating ``apply()`` shows that use of the warning
+framework can incur a significant performance penalty.
+
+Code which instantiates explicitly would not be affected, since the
+run-time checks necessary to determine whether to issue a warning are
+exactly those which are needed to determine whether to instantiate
+implicitly in the first place.  That is, such statements are already
+incurring the cost of these checks.
+
+Code which instantiates implicitly would incur a large cost: timing
+trials indicate that issuing a warning (whether it is suppressed or
+not) takes about five times more time than simply instantiating,
+raising, and catching an exception.
+
+This penalty is mitigated by the fact that ``raise`` statements are
+rarely on performance-critical execution paths.
+
+
+Traceback Argument
+------------------
+
+As the proposal stands, it would be impossible to use the traceback
+argument to ``raise`` conveniently with all 2.x versions of Python.
+
+For compatibility with versions < 2.4, the three-argument form must be
+used; but this form would produce warnings with versions >= 2.4.
+Those warnings could be suppressed, but doing so is awkward because
+the relevant type of warning is issued at compile-time.
+
+If this PEP were still under consideration, this objection would be
+met by extending the phase-in period.  For example, warnings could
+first be issued in 3.0, and become errors in some later release.
+
+
 References
 ==========
 
@@ -330,6 +445,9 @@ References
 .. [5] PEP 230 "Warning Framework", Guido van Rossum.
        http://www.python.org/peps/pep-0230.html
 
+.. [6] Guido van Rossum, 11 June 2003 post to ``python-dev``.
+       http://mail.python.org/pipermail/python-dev/2003-June/036176.html
+
 
 Copyright
 =========