Withdraw PEP 531 based on python-ideas discussion

ncoghlan · ncoghlan · commit 9a70e511ada6 · 2016-10-30T11:51:23.000+10:00
diff --git a/pep-0531.txt b/pep-0531.txt
@@ -3,7 +3,7 @@ Title: Existence checking operators
 Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Coghlan <ncoghlan@gmail.com>
-Status: Draft
+Status: Withdrawn
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 25-Oct-2016
@@ -52,6 +52,53 @@ following characteristics:
   (zeroes, empty containers) will still evaluate to True in an existence
   checking context
 
+PEP Withdrawal
+==============
+
+When posting this PEP for discussion on python-ideas [4_], I asked reviewers to
+consider 3 high level design questions before moving on to considering the
+specifics of this particular syntactic proposal:
+
+1. Do we collectively agree that "existence checking" is a useful
+general concept that exists in software development and is distinct
+from the concept of "truth checking"?
+2. Do we collectively agree that the Python ecosystem would benefit
+from an existence checking protocol that permits generalisation of
+algorithms (especially short circuiting ones) across different "data
+missing" indicators, including those defined in the language
+definition, the standard library, and custom user code?
+3. Do we collectively agree that it would be easier to use such a
+protocol effectively if existence-checking equivalents to the
+truth-checking "and" and "or" control flow operators were available?
+
+While the answers to the first question were generally positive, it quickly
+became clear that the answer to the second question is "No".
+
+Steven D'Aprano articulated the counter-argument well in [5_], but the general
+idea is that when checking for "missing data" sentinels, we're almost always
+looking for a *specific* sentinel value, rather than *any* sentinel value.
+
+``NotImplemented`` exists, for example, due to ``None`` being a potentially
+legitimate result from overloaded arithmetic operators and exception
+handling imposing too much runtime overhead to be useful for operand coercion.
+
+Similarly, ``Ellipsis`` exists for multi-dimensional slicing support due to
+``None`` already have another meaning in a slicing context (indicating the use
+of the default start or stop indices, or the default step size).
+
+In mathematics, the value of ``NaN`` is that *programmatically* it behaves
+like a normal value of its type (e.g. exposing all the usual attributes and
+methods), while arithmetically it behaves according to the mathematical rules
+for handling ``NaN`` values.
+
+With that core design concept invalidated, the proposal as a whole doesn't
+make sense, and it is accordingly withdrawn.
+
+However, the discussion of the proposal did prompt consideration of a potential
+protocol based approach to make the existing ``and``, ``or`` and ``if-else``
+operators more flexible [6_] without introducing any new syntax, so I'll be
+writing that up as another possible alternative to PEP 505.
+
 
 Relationship with other PEPs
 ============================
@@ -584,6 +631,14 @@ References
 .. [3] FileFormat.info: Unicode Character 'THERE EXISTS' (U+2203)
    (http://www.fileformat.info/info/unicode/char/2203/index.htm)
 
+.. [4] python-ideas discussion thread
+   (https://mail.python.org/pipermail/python-ideas/2016-October/043415.html)
+
+.. [5] Steven D'Aprano's critique of the proposal
+   (https://mail.python.org/pipermail/python-ideas/2016-October/043453.html)
+
+.. [6] Considering a link to the idea of overloadable Boolean operators
+   (https://mail.python.org/pipermail/python-ideas/2016-October/043447.html)
 
 Copyright
 =========
