From 9a70e511ada63b976699bbab9da142379340758c Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Sun, 30 Oct 2016 11:51:23 +1000 Subject: [PATCH] Withdraw PEP 531 based on python-ideas discussion --- pep-0531.txt | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 56 insertions(+), 1 deletion(-) diff --git a/pep-0531.txt b/pep-0531.txt index 4f84399ef..d45ef45bc 100644 --- a/pep-0531.txt +++ b/pep-0531.txt @@ -3,7 +3,7 @@ Title: Existence checking operators Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan -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 =========