Ethan Furman wrote: > On 8/23/21 2:31 PM, Tim Hoffmann via Python-ideas wrote: > > Ethan Furman wrote: > > > It seems to me that the appropriate fix is for numpy to have an > > > "is_empty()" function > > that knows how to deal with arrays and array-like structures, not force > > every container > > to grow a new method. > > Yes, numpy could and probably should have an "is_empty()" method. However, > > defining a > > method downstream breaks duck typing and maybe even more important authors > > have to > > mentally switch between the two empty-check variants `if users` and `if > > users.is_empty()` > > depending on the context. > > The context being whether or not you working with numpy? Is there generic > > code that works with both numpy arrays and > other non-numpy data? Do we have any non-numpy examples of this problem?
E.g. SciPy and Matplotlib accept array-like inputs such as lists of numbers. They often convert internally to numpy arrays, but speaking for the case of Matplotlib, we sometimes need to preseve the original data and/or delay conversion, so we have to take extra care when checking inputs. Pandas has the same Problem. "The truth value of a DataFrame is ambiguous". They have introduced a `DataFrame.empty` property. I suspect the same problem exists for other types like xarray or tensorflow tensors, but I did not check. > > If you want to write a function that accepts array-like `values`, you have > > to change > > a check `if values` to `if len(values) == 0`. That works for both but is > > against the > > PEP8 recommendation. This is a shortcoming of the language. > > Numpy is not Python, but a specialist third-party package that has made > > specialist > > choices about basic operations -- that does not sound like a shortcoming of > > the language. > > The "specialist choices" ``if len(values) == 0` in Numpy are the best you > > can do within > > the capabilities of the Python language if you want the code to function > > with lists and > > arrays. For Numpy to do better Python would need to either provide the > > above mentioned > > "has element-wise operations" protocol or an is_empty protocol. > > I consider emptiness-check a basic concept that should be consistent and > > easy to use across containers. > Python has an emptiness-check and numpy chose to repurpose it -- that is not > Python's problem nor a shortcoming in Python. Python does not have an emptiness-check. Empty containers map to False and we suggest in PEP8 to use the False-check as a stand in for the emptiness-check. But logically falsiness and emptiness are two separate things. Numpy (IMHO with good justification) repurposed the False-check, but that left them without a standard emptiness check. > Suppose we add an `.is_empty()` method, and five years down the road another > library repurposes that method, that other > library then becomes popular, and we then have two "emptiness" checks that > are no longer consistent -- do we then add a > third? I don't think this is a valid argument. We would introduce the concept of emptiness. That can happen only once. What empty means for an object is determined by the respective library and implemented there, similar to what `len` means. There can't be any inconsistency. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CPW43PRUJ7X4Y3SWMTA26LIPKAECAV55/ Code of Conduct: http://python.org/psf/codeofconduct/
