On Jun 19, 2019, at 15:28, Soni L. <fakedme+py@gmail.com> wrote:
I'm parsing configs for domain filtering rules, and they come as a list. However, str.endswith requires a tuple. So I need to use str.endswith(tuple(list)). I don't know the reasoning for this, but why not just accept a list as well?
Strings are iterables. So, if endswith could accept arbitrary iterables, then endswith('abc') would mean the same as endswith(['a', 'b', 'c']), which would be very confusing. Or there’d be some special exception so it wouldn’t mean that when the iterable is a string, which might be less newbie-confusing, but would be even more confusing when you try to learn the details. (What would the details be? Remember that there’s also bytes.endswith, and bytearray.endswith, and they surely don’t want to distinguish with isinstance(arg, str), and even isinstance(arg, type(self)) is probably a bad idea unless you don’t want a bytearray to be able to take a bytes argument.) A better solution would be *args, so you don’t need a single argument that’s either a string or multiple strings. That’s how newer functions do “one or more whatevers”. The only problem is that *args didn’t exist at the time endswith was created (nor did the concept of “arbitrary iterable”). All of the old functions that do this (and a few newer functions that had good reasons to exactly ape the API of one of the old functions) use the same tuple-is-special rule, so you probably wouldn’t want to change one without changing all of them. And, if it wasn’t worth changing them in 2.2 or even 3.0 (presumably because backward compatibility outweighed the benefits), it probably isn’t worth changing them today either, but maybe you could make a case otherwise.