I\'ve been playing for a bit with startswith()
and I\'ve discovered something interesting:
>>> tup = (\'1\', \'2\', \'3\')
>>>
This has already been suggested on Python-ideas a couple of years back see: str.startswith taking any iterator instead of just tuple and GvR had this to say:
The current behavior is intentional, and the ambiguity of strings themselves being iterables is the main reason. Since
startswith()
is almost always called with a literal or tuple of literals anyway, I see little need to extend the semantics.
In addition to that, there seemed to be no real motivation as to why to do this.
The current approach keeps things simple and fast,
unicode_startswith (and endswith
) check for a tuple argument and then for a string one. They then call tailmatch in the appropriate direction. This is, arguably, very easy to understand in its current state, even for strangers to C code.
Adding other cases will only lead to more bloated and complex code for little benefit while also requiring similar changes to any other parts of the unicode object.