On Oct 13, 2019, at 04:56, Steve Jorgensen <ste...@stevej.name> wrote:
>
> 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?
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YJTU2UKRADDYKLFBWHXSE5WOKGF2D5OD/
Code of Conduct: http://python.org/psf/codeofconduct/
