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.
In my experience, if you didn't write the function that creates the list, there's a solid chance it could be None too, and if you try to check the length of None, you get an error. This is also why returning None when a function fails is bad practice IMO, but that doesn't seem to stop my coworkers.
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.
In my experience, if you didn't write the function that creates the list, there's a solid chance it could be
None
too, and if you try to check the length ofNone
, you get an error. This is also why returningNone
when a function fails is bad practice IMO, but that doesn't seem to stop my coworkers.Passing None to a function expecting a list is the error...