On 29 October 2016 at 21:44, Steven D'Aprano email@example.com wrote:
On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:
- 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"?
Not speaking for "we", only for myself: of course.
- 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?
Maybe, but probably not.
Checking for "data missing" or other sentinels is clearly an important thing to do, but it remains to be seen whether (1) it should be generalised and (2) there is a benefit to making it a protocol.
My sense so far is that generalising beyond None is YAGNI. None of the other examples you give strike me as common enough to justify special syntax, or even a protocol. I'm not *against* the idea, I just remain unconvinced.
I considered this the weakest link in the proposal when I wrote it, and the discussion on the list has persuaded me that it's not just a weak link, it's a fatal flaw. Accordingly, I've withdrawn the PEP, and explained why with references back to this discussion: https://github.com/python/peps/commit/9a70e511ada63b976699bbab9da14237934075...
However, as noted there, I find the possible link back to the rejected boolean operator overloading proposal in PEP 335 interesting, so I'm going to invest some time in writing that up to the same level as I did the existence checking one (i.e. Abstract, Rationale & design discussion, without a full specification or reference implementation yet).