On Wed, 25 Aug 2021 at 14:00, Tim Hoffmann via Python-ideas <python-ideas@python.org> wrote: > > I can agree that "len(c) == 0" should mean "c is empty" for all practical > purposes (and numpy and pandas conform with that).
OK > But "bool(c)" should mean "c is empty" is an arbitrary additional constraint. > For some types (e.g. numpy, padas) that cannot be fulfilled in a logically > consisent way. By requiring that additional constraint, the Python languages > forces these containers to be a special case. It's another way of expressing the intent, which is potentially useful if you don't care about those special cases. We're all consenting adults here, there's no "constraint" involved. > To sum things up, I've again written the > > Premise: > It is valuable for the language and ecosystem to not have this special > casing. I.e. I don't want to write `if not seq` on the one hand and `if > len(array) == 0`. The syntax for checking if a list or an array is empty > should be the same. The *language* (by which I assume you mean "Python") doesn't have any special casing. It just has behaviour. It's valuable for educating beginners, maybe, to have an easily expressed way of checking for emptiness, but for "the language and ecosystem"? I don't think so - it's valuable to allow people to express their intent in the way that is most natural to them, IMO. > Conclusion: > If so, PEP-8 has to be changed because "For sequences, (strings, lists, > tuples), use the fact that empty sequences are false:" is not a universal > solution. "Has to be" is extremely strong here. PEP 8 is a set of *guidelines* that people should use with judgement and thought, not a set of rules to be slavishly followed. And in fact, I'd argue that describing a numpy array or a Pandas dataframe as a "sequence" is pretty inaccurate anyway, so assuming that the statement "use the fact that empty sequences are false" applies is fairly naive anyway. But if someone wants to alter PEP 8 to suggest using len() instead, I'm not going to argue, I *would* get cross, though, if the various PEP 8 inspired linters started complaining when I used "if seq" to test sequences for emptiness. > The question then is, what other syntax to use for an emptiness check. > > Possible solutions: > 1) The length check is a possible solution: > "For sequences, (strings, lists, tuples), test emptiness by `if len(seq) == > 0`. > N.b. I think this is more readable than the variant `if not len(seq)` (but > that could be discussed as well). If someone is reading PEP 8 and can't make their own choice between "if len(seq) == 0" and "if not len(seq)" then they should go and read a Python tutorial, not expect the style guide to tell them what to do :-( > 2) The further question is: If we change the PEP 8 recommendation anyway, can > we do better than the length check? > IMHO a length check is semantically on a lower level than an empty-check. > Counting elements is a more detailed operation than only checking if we have > any element. That detail is not needed and distracting if we are only > interested in is_empty. This is vaguely similar to iterating over indices > (`for i in range(len(users))`) vs. iterating over elements (`for user in > users`). We don't iterate over indices because that's usually a detail we > don't need. So one can argue we shouldn't count elements if we only wan to > know if there are any. Not without either changing the language/stdlib or recommending a user-defined function or 3rd party library. To put that another way, the current Python language and stdlib doesn't currently have (or need, IMO) a better way of checking for emptiness. If you want to argue that it needs one, you need an argument far better than "to have something to put in PEP 8". > If we come to the conclusion that an explicit empty check is better than a > length=0 check, there are again different ways how that could be implmented > again. My favorite solution now would be adding `is_empty()` methods to all > standard containers and encourage numpy and pandas to add these methods as > well. (Alternatively an empty protocol would be a more formal solution to an > explicit check). Well, that's "if false then ..." in my opinion. I.e., I don't think you've successfully argued that an explicit empty check is better, and I don't think you have a hope of doing so if your only justification is "so we can recommend it in PEP 8". Paul _______________________________________________ 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/WGJ5COO3WSVXF5RORT6KRQQHL5GILQXI/ Code of Conduct: http://python.org/psf/codeofconduct/
