On Tue, 24 Aug 2021 at 12:07, Tim Hoffmann via Python-ideas
Just like length is. It's a basic concept and like __bool__ and __len__ it should be upon the objects to specify what empty means.
It feels like these arguments in the abstract are mostly going round in circles. It's possible something has been mentioned earlier in this thread, but I don't recall if so - but is there any actual real-world code that would be substantially improved if we had built into the language a protocol that users could override in their classes to explicitly define what "is empty" meant for that class? Some things to consider: 1. It would have to be a case where neither len(x) == 0 or bool(x) did the right thing. 2. We can discount classes that maliciously have bizarre behaviour, I'm asking for *real world* use cases. 3. It would need to have demonstrable benefits over a user-defined "isempty" function (see below). 4. Use cases that *don't* involve numpy/pandas would be ideal - the scientific/data science community have deliberately chosen to use container objects that are incompatible in many ways with "standard" containers. Those incompatibilities are deeply rooted in the needs and practices of that ecosystem, and frankly, anyone working with those objects should be both well aware of, and comfortable with, the amount of special-casing they need. To illustrate the third point, we can right now do the following: from functools import singledispatch @singledispatch def isempty(container): return len(container) == 0 # If you are particularly wedded to special methods, you could even do # # @singledispatch # def isempty(container): # if hasattr(container, "__isempty__"): # return container.__isempty() # return len(container) == 0 # # But frankly I think this is unnecessary. I may be in a minority here, though. @isempty.register def _(arr: numpy.ndarray): return len(arr.ravel()) == 0 So any protocol built into the language needs to be somehow better than that. If someone wanted to propose that the above (default) definition of isempty were added to the stdlib somewhere, so that people could register specialisations for their own code, then that might be more plausible - at least it wouldn't have to achieve the extremely high bar of usefulness to warrant being part of the language itself. I still don't think it's sufficiently useful to be worth having in the stdlib, but you're welcome to have a go at making the case... Paul