On Fri, Oct 28, 2016 at 11:17 AM, Paul Moore email@example.com wrote:
On 28 October 2016 at 15:40, Nick Coghlan firstname.lastname@example.org wrote:
I also don't think the idea is sufficiently general to be worthy of dedicated syntax if it's limited specifically to "is not None" checks
- None's definitely special, but it's not *that* special. Unifying
None, NaN, NotImplemented and Ellipsis into a meta-category of objects that indicate the absence of information rather than a specific value, though?
First thing is that I definitely DO NOT want new SYNTAX to do this. I wouldn't mind having a new built-in function for this purpose if we could get the call signature right. Maybe it would be called 'exists()', but actually something like 'valued()' feels like a better fit.
For the unusual case where the "null-coalescing" operation is what I'd want, I definitely wouldn't mind something like Barry's proposal of processing a string version of the expression. Sure, *some* code editors might not highlight it as much, but it's a corner case at most, to my mind. For that, I can type 'valued("x.y.z[w]", coalesce=ALL)' or whatever.
However, I'm not convinced by your proposal that we can unify None, NaN, NotImplemented and Ellipsis in the way you suggest. I wouldn't expect a[1, None, 2] to mean the same as a[1, ..., 2], so why should an operator that tested for "Ellipsis or None" be useful?
I *especially* think None and nan have very different meanings. A list of [1.1, nan, 3.3] means that I have several floating point numbers, but one came from a calculation that escaped the real domain. A list with [1.1, None, 3.3] means that I have already calculated three values, but am marking the fact I need later to perform a calculation to figure out the middle one. These are both valid and important use cases, but they are completely different from each other.