[Python-checkins] python/nondist/peps pep-0000.txt,1.245,1.246 pep-0317.txt,1.2,1.3
goodger@users.sourceforge.net
goodger@users.sourceforge.net
Mon, 16 Jun 2003 16:46:49 -0700
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv27121
Modified Files:
pep-0000.txt pep-0317.txt
Log Message:
reject PEP 317, with summary from author
Index: pep-0000.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v
retrieving revision 1.245
retrieving revision 1.246
diff -C2 -d -r1.245 -r1.246
*** pep-0000.txt 14 Jun 2003 22:40:36 -0000 1.245
--- pep-0000.txt 16 Jun 2003 23:46:47 -0000 1.246
***************
*** 117,121 ****
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
--- 117,120 ----
***************
*** 186,189 ****
--- 185,189 ----
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
***************
*** 329,333 ****
S 315 Enhanced While Loop Carroll
SD 316 Programming by Contract for Python Way
! S 317 Eliminate Implicit Exception Instantiation Taschuk
S 318 Function/Method Decorator Syntax Smith
S 319 Python Synchronize/Asynchronize Block Pelletier
--- 329,333 ----
S 315 Enhanced While Loop Carroll
SD 316 Programming by Contract for Python Way
! SR 317 Eliminate Implicit Exception Instantiation Taschuk
S 318 Function/Method Decorator Syntax Smith
S 319 Python Synchronize/Asynchronize Block Pelletier
Index: pep-0317.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0317.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** pep-0317.txt 9 Jun 2003 04:43:39 -0000 1.2
--- pep-0317.txt 16 Jun 2003 23:46:47 -0000 1.3
***************
*** 4,13 ****
Last-Modified: $Date$
Author: Steven Taschuk <staschuk@telusplanet.net>
! Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 06-May-2003
Python-Version: 2.4
! Post-History:
--- 4,13 ----
Last-Modified: $Date$
Author: Steven Taschuk <staschuk@telusplanet.net>
! Status: Rejected
Type: Standards Track
Content-Type: text/x-rst
Created: 06-May-2003
Python-Version: 2.4
! Post-History: 09-Jun-2003
***************
*** 313,316 ****
--- 313,431 ----
+ 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,333 ****
--- 445,451 ----
.. [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