On Sat, Oct 29, 2016 at 3:53 AM, Steven D'Aprano firstname.lastname@example.org wrote:
Hmmm. I see your point, but honestly, None *is* special. Even for special objects, None is even more special.
As a contributor to and user of many numerical computing libraries in Python (e.g., NumPy, pandas, Dask, TensorFlow) I also agree here.
Implicit non-existence for NotImplemented and Ellipsis seem particularly problematic, because these types are rarely used, and the meaning of these types intentionally differs from other missing types: - In NumPy, None is a valid indexing argument, used as a sentinel marker for "insert a new axis here". Thus x[..., None] means "insert a new axis at the end." - Likewise, implicit checks for NotImplemented would be problematic in arithmetic, because NaN is also a perfectly valid result value for arithmetic. Especially in this case, checking for "missingness" could look attractive at first glance to implementors of special methods for arithmetic but could later lead to subtle bugs.
I'm have more mixed fillings on testing for NaNs. NaNs propagate, so explicit testing is rarely needed. Also, in numerical computing we usually work with arrays of NaN, so operator.exists() and all this nice syntax would not be a substitute for numpy.isnan or pandas.isnull.
On the whole, I do think that adding systematic checks for None to Python with dedicate syntax would be a win. If making NaN "missing" and allowing user defined types to be "missing" would help make that happen, then sure, go ahead, but I see few use cases.