Why doesn't python's list append() method return the list itself?

[Nathan Rice]

Stephen:

I'm not adverse to being able to do that, but the number of times that I've
wanted to do that is greatly outweighed by the number of times I've had to
pass a function "(somestring,)" or call "if isinstance(foo, basestring):
..." to avoid producing a bug.  The more abstract and adaptive the code you
are writing, the more annoying it gets - you end up with a rats nest of
string instance checks and strings wrapped in tuples.  Looking at my code, I
don't have a lot of use cases for string slicing or iterating character by
character.

Most of the time I use the string methods, they're faster and (IMO) clearer
- lower, index/rindex, find, etc.  One use case that I avoid is extracting
substrings, by slicing out the results of rfind.  There's a good case for
this but I feel it's brittle so I usually just jump to regular expressions
(and it could be performed equally well with a substring method).  That
doesn't mean I don't think it's useful, just that as it stands the default
language behavior is bug producing, and in my opinion people would be
equally well served with an as_list method on strings that makes the
behavior explicit.


Chris:

Let's not run around questioning people's math skills, that's actually my
area of expertise, and it's impolite besides :)

While having all([]) return True from a formal standpoint "makes sense" it
typically reduces people to writing "if all(something) and something:",
because feeding an iterable that has been filtered in some way (and thus has
a range between 0 and n, where n is the length of the original iterable) is
an incredibly common use case.  In fact, I'm going to go out on a limb here
and say there are a lot of bugs floating around that haven't been caught
because the code author used all() under the assumption that it would be
passed a non-empty list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100712/85a1eaca/attachment-0001.html>