Steven D'Aprano wrote:
... if not li says nothing about what li is supposed to 'be'
Yes, and? Neither does:
isempty(li) # li could be anything that polymorphic isempty can deal with
li.isempty() # li could be anything with a "isempty" method
len(li) == 0 # li could be anything with a length (list, dict, set, ...)
Sure.
That's duck-typing for you, and it is generally a strength rather than a
weakness. For those times when it is a weakness, that's where we have
naming conventions, type-testing, and (in some languages) static types.
I can fix almost anything with duck-type... :)
> and implies in any case that li does not exist
It does nothing of the sort. If li doesn't exist, you get a NameError.
That was the point. 'not' implies something that is not logical;
which is irony extreme since 'not' is typically considered a logical
operator. What does it mean to say not <list name>? Well, apparently
it means the list is 'empty'... but why should it mean that? Why not
have it mean the list has been reversed in place? Why not have it mean
that the list isn't homogeneous? Why not have it mean that its not
mutable? I could think of more... Why should 'not' mean 'empty'?
> or worse is some kind of boolean.
Only if you're still thinking in some language that isn't Python.
Which most of us are... hate to remind you... Python is the new
kid on the block, and most of us are coming at this from multiple
filters in comp sci experience. Its just the truth.
> Why not have a list method that makes this more explicit:
For the same reason that we don't have an int method that makes zero
testing more explicit:
Because sometimes you can have too much explicitness.
True.
kind regards,
m harris
--
http://mail.python.org/mailman/listinfo/python-list
