[Python-checkins] peps: PEP 3150: Withdraw this for the last time. It's a bad idea

[nick.coghlan]

http://hg.python.org/peps/rev/bdc181755fb3
changeset:   4067:bdc181755fb3
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Wed Feb 22 01:00:58 2012 +1000
summary:
  PEP 3150: Withdraw this for the last time. It's a bad idea

files:
  pep-3150.txt |  50 ++++++++++-----------------------------
  1 files changed, 13 insertions(+), 37 deletions(-)


diff --git a/pep-3150.txt b/pep-3150.txt
--- a/pep-3150.txt
+++ b/pep-3150.txt
@@ -3,7 +3,7 @@
 Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Coghlan <ncoghlan at gmail.com>
-Status: Deferred
+Status: Withdrawal
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 2010-07-09
@@ -47,45 +47,21 @@
 but has not yet itself been subject to the test of implementation.
 
 
-PEP Deferral
-============
+PEP Withdrawal
+==============
 
-Despite the lifting of the language moratorium (PEP 3003) for Python 3.3,
-this PEP currently remains in a Deferred state. This idea, if implemented,
-will potentially have a deep and pervasive effect on the way people write
-Python code.
+I've had a complicated history with this PEP. For a long time I left it in
+the Deferred state because I wasn't convinced the additional complexity was
+worth the payoff. Then, briefly, I became more enamoured of the idea and
+only left it at Deferred because I didn't really have time to pursue it.
 
-When this PEP was first put forward, even I, as the PEP author, was not
-convinced it was a good idea. Instead, I was simply writing it as a way to
-avoid endlessly rehashing similar topics on python-ideas. When someone
-broached the subject, they could be pointed at this PEP and told "Come back
-when you've read and understood the arguments presented there". Subsequent
-discussions (most notably, those surrounding PEP 403's attempt at a more
-restricted version of the idea) have convinced me that the idea is valuable
-and will help address a number of situations where developers feel that
-Python "gets in the way" instead of "matching the way they think". For me,
-it is this aspect of "let people express what they're thinking, rather than
-forcing them to think differently due to Python's limitations" that finally
-allowed the idea to clear the "status quo wins a stalemate" bar ([5]_).
+I'm now withdrawing it, as, the longer I reflect on the topic, the more I
+feel this approach is simply far too intrusive and complicated to ever be
+a good idea for Python as a language.
 
-However, while I now think the idea is worthwhile, I don't think there is
-sufficient time left in the 3.3 release cycle for the idea to mature. A
-reference implementation is needed, and people need time to experiment with
-that implementation and offer feedback on whether or not it helps with
-programming paradigms that are currently somewhat clumsy in Python (like
-callback programming). Even if a PEP co-author volunteered immediately to
-work on the implementation and incorporate feedback into the PEP text, I feel
-targetting 3.3 would be unnecessarily rushing things. So, I've marked this
-PEP as a candidate for 3.4 rather than 3.3.
-
-Once that process is complete, Guido van Rossum (or his delegate) will need 
-to be sufficiently convinced of the idea's merit and accept the PEP. Such
-acceptance will require not only a fully functional reference implementation
-for CPython (as already mentioned), but also indications from the other three
-major Python implementations (PyPy, Jython, IronPython) that they consider
-it feasible to implement the proposed semantics once they reach the point of
-targetting 3.4 compatibility. Input from related projects with a vested
-interest in Python's syntax (e.g. Cython) will also be valuable.
+I've also finally found a couple of syntax proposals for PEP 403 that
+read quite nicely and address the same set of use cases as this PEP
+while remaining significantly simpler.
 
 
 Proposal

-- 
Repository URL: http://hg.python.org/peps