<div>Stephen:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Chris:</div><div><br></div>Let's not run around questioning people's math skills, that's actually my area of expertise, and it's impolite besides :)<div><br></div><div>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.</div>
<div><div><br></div><div><br></div></div>