On 28 October 2016 at 15:40, Nick Coghlan <ncogh...@gmail.com> 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? And also allowing developers to emulate the protocol for > testing purposes? That's enough to pique my interest.
I think that's the key for me - new syntax for "is not None" types of test seems of limited value (sure, other languages have such things, but that's not compelling - the contexts are different). 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? Same for NotImplemented - we're not proposing to allow rich comparison operators to return None rather than NotImplemented. The nearest to plausible is NaN vs None - but even there I don't see the two as the same. So, to answer your initial questions, in my opinion: 1. The concept of "checking for existence" is valid. 2. I don't see merging domain-specific values under a common "does not exist" banner as useful. Specifically, because I wouldn't want the "does not exist" values to become interchangeable. 3. I don't think there's much value in specific existence-checking syntax, precisely because I don't view it as a good thing to merge multiple domain-specific "does not exist", and therefore the benefit is limited to a shorter way of saying "is not None". As you noted, given my answers to 1-3, there's not much point in considering the remaining questions. However, I do think that there's another concept tied up in the proposals here, that of "short circuiting attribute access / indexing". The call was for something that said roughly "a.b if a is not None, otherwise None". But this is only one form of this pattern - there's a similar pattern, "a.b if a has an attribute b, otherwise None". And that's been spelled "getattr(a, 'b', None)" for a long time now. The existence of getattr, and the fact that no-one is crying out for it to be replaced with syntax, implies to me that before leaping to a syntax solution we should be looking at a normal function (possibly a builtin, but maybe even just a helper). I'd like to see a justification for why "a.b if a is not None, else None" deserves syntax when "a.b if a has attribute b, else None" doesn't. IMO, there's no need for syntax here. There *might* be some benefit in some helper functions, though. The cynic in me wonders how much of this debate is rooted in the fact that it's simply more fun to propose new syntax, than to just write a quick helper and get on with coding your application... Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
