On Oct 13, 2019, at 04:56, Steve Jorgensen
Those are good points, so what about a new method for this rather than an additional behavior for the existing method? After all, "explicit is better than implicit".
New method names could be something like "beginswith_any" and "endswith_any", "find_any", "index_any", "count_any", ….
This solves the backward compatibility problem. And I don’t think it doubles the cognitive load; you just have to remember the single new `_any` suffix, as long as it’s consistent so you don’t need to remember a lot of exceptions. But it does double the help text, docs, etc. Which will make it harder to look things up, and require more maintenance work to make sure you copy-and-paste-and-edit the docstring for two methods every time you add or modify one, and so on. If this really needs to be fixed, what’s wrong with using *args? For backward compatibility, a single arg continues to be “str or tuple of str”, but for new uses going forward you just never pass a tuple and instead write `x.endswith('spam', 'eggs', 'cheese')` or `x.endswith(*suffixes)` instead of `x.endswith(('spam', 'eggs', 'cheese'))` or `x.endswith(tuple(suffixes))`? That makes it consistent with everything else in Python, instead of requiring you to learn that string methods are special and have `_any` variants (and you only have to learn that string methods are special and take tuples if you’re implementing a new string method). It seems like this provides all the same benefits plus an extra one with no added cost. But I’m not sure why it needs to be fixed. As I said last time, nobody apparently thought it needed to be fixed in 2.2 or 3.0, so… why was that the wrong decision?