I write a lot of Python. I hate it when people use “X is more pythonic” as some kind of argument for what is a better solution to a problem. I also have a hang up with people acting like python has any form of type safety, instead of just embracing duck typing.This lands us at the following:
The article states that “you can check a list for emptiness in two ways:
if not mylistorif len(mylist) == 0”. Already here, a fundamental mistake has been made: You don’t know (and shouldn’t care) whethermylistis a list. These two checks are not different ways of doing the same thing, but two different checks altogether. The first checks whether the object is “falsey” and the second checks whether the object has a well defined length that is zero. These are two completely different checks, which often (but far from always) overlap. Embrace the duck type- type safe python is a myth.isn’t the expected behaviour exactly identical on any object that has len defined:
“By default, an object is considered true unless its class defines either a bool() method that returns False or a len() method that returns zero, when called with the object.”
How does Python know if it’s my list or not?
Telemetry
if isinstance(mylist, list) and not mylistProblem solved.
Or
if not mylist # check if list is emptyI think you missed the joke 😅
You’re checking if
mylistis falsey. Sometimes that’s the same as checking if it’s empty, if it’s actually a list, but that’s not guaranteed.Doesn’t Python treat all empty iterables as false tho? This isn’t unique to python, is it? (though I’m not a programmer…just a dude who writes scripts every now and then)
My point is that the second statement you presented can have the effect of evaluating emptiness of a Sequence (note: distinct from an Iterable), but that only holds true if the target of the conditional IS a sequence. I’m underlining the semantic difference that was elided as a result of falsey evaluation.
Yea and then you use “not” with a variable name that does not make it obvious that it is a list and another person who reads the code thinks it is a bool. Hell a couple of months later you yourself wont even understand that it is a list. Moreover “not” will not throw an error if you don’t use an sequence/collection there as you should but len will.
You should not sacrifice code readability and safety for over optimization, this is phyton after all I don’t think list lengths will be your bottle neck.
Removed by mod
well it does not imply directly per se since you can “not” many things but I feel like my first assumption would be it is used in a bool context
I would say it depends heavily on the language. In Python, it’s very common that different objects have some kind of Boolean interpretation, so assuming that an object is a bool because it is used in a Boolean context is a bit silly.
Well fair enough but I still like the fact that len makes the aim and the object more transparent on a quick look through the code which is what I am trying to get at. The supporting argument on bools wasn’t’t very to the point I agree.
That being said is there an application of “not” on other classes which cannot be replaced by some other more transparent operator (I confess I only know the bool and length context)? I would rather have transparently named operators rather than having to remember what “not” does on ten different types. I like duck typing as much as the next person, but when it is so opaque (name-wise) as in the case of “not”, I prefer alternatives.
For instance having open or read on different objects which does really read or open some data vs not some object god knows what it does I should memorise each case.
Removed by mod
if not x then … endis very common in Lua for similar purposes, very rarely do you see hard nil comparisons or calls totypeof(last time I did was for a serializer).
You can make that assumption at your own peril.
I don’t think they are a minority
If anything len tells you that it is a sequence or a collection, “not” does not tell you that. That I feel like is the main point of my objection.
Removed by mod
It does if you are used to sane languages instead of the implicit conversion nonsense C and the “dynamic” languages are doing
so these are the only 2 ways then? huge if true
Could also compare against:
if not len(mylist)That way this version isn’t evaluating two functions. The bool evaluation of an integer is false when zero, otherwise true.
As a Perl fossil I recognise this syntax as equivalent to
if(not @myarray)which does the same thing. And here I was thinking Guido had deliberately aimed to avoid Perlisms in Python.That said, the Perlism in question is the right* way to do it in Perl. The
lengthoperator does not do the expected thing on an array variable. (You get the length of the stringified length of the array. And a warning if those are enabled.)* You can start a fight with modern Perl hackers with whether
unless(@myarray)is better or just plain wrong, even if it works and is equivalent.
