On Mar 5, 2020, at 08:27, Christopher Barker <python...@gmail.com> wrote: > >> On Wed, Mar 4, 2020 at 8:13 PM Andrew Barnert via Python-ideas >> <python-ideas@python.org> wrote: > >> Sorry, I thought I was replying to something from today, not a year ago. > > Which is fine — that conversation kind of petered out anyway, and I think > reviving it is a fine idea. > > It sounds like you at least like the idea, so maybe it’s time to reframe the > conversation into “how should we do it” rather than “should we do it”. Of > course, in the end, a decision can’t be made without a specific > implementation, but it’s good to know if it’ll even be considered.
Well, I like the idea if someone can come up with a good naming scheme—something that at least reminds me which function is the “set of chars” stripper and which the “substring” stripper, rather than just being two synonyms that people are going to get backward as often as they get them right (and even worse if they’re familiar with another popular language), and something that doesn’t gratuitously add yet another way to say l/left/start (like prefix). And, while I haven’t reread the entire old thread, I don’t think any of the suggestions so far qualified, and I don’t think my own suggestion is that great. > For my part, I prefer new methods over keyword parameters: > > 1) I don’t think any other string methods take keywords. Sure, but they mostly go back to the days before keyword arguments existed at all, much less now when they can be implemented relatively easily even in C functions. > 2) I believe Guido is credited with saying something like: it’s better to > write two functions than have one function that takes a keyword argument that > selects between two behaviors. Yes, but it’s also better to have a function that takes two different keyword arguments than a function that takes one positional argument and type-switches on it to select between two behaviors. The string-or-tuple-of-strings idiom is as clunky as similar things like file-or-contents and file-or-pathname. Although for the case of startswith and friends, there’s another option that didn’t exist in Python 1.0 but does today: startswith(self, *strings), which allows you to write a.startswith(*set_of_prefixes) without caring that you have a set rather than a tuple and without danger of confusing a string vs. a collection of strings. When adding new code that really needs to be consistent with existing APIs, it makes sense to ape those APIs even if they’re clunky, but I’m not convinced that’s necessary here. But if so, fine. If we need to take a string or strings, and we need to be consistent with the rest of the str API and not take keywords, that sounds like a job for a new method, as long as that method actually implies or at least mnemonically helps with “string or strings rather than character set”, like my lstrip_string suggestion.
_______________________________________________ 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/6PMLGEB6LXGFVVYRCVUBA7DE2P22NBYQ/ Code of Conduct: http://python.org/psf/codeofconduct/
