On Sat, Mar 30, 2019 at 10:21:23AM +0000, Paul Moore wrote:
On Fri, 29 Mar 2019 at 23:07, Christopher Barker <pythonchb@gmail.com> wrote:
The proposal at hand is to add two fairly straightforward methods to string. So:
Some of what you are calling digressions are actually questioning the design choice behind that proposal. Specifically, there's no particular justification given for making these methods rather than standalone functions.
Strings are objects and Python is an object-oriented language. Surely the default presumption ought to be that string functionality goes into the string object as methods, not a seperate function, unless they're so specialised, or so large and unwieldy, that they ought to go into a module. There's a cost to moving functionality into a seperate module. Its harder to discover functions buried in a module when most of the string functionality is in str itself, and its rather a nuisance to write (e.g.): unicodedata.name('x') instead of 'x'.name(). I use unicodedata *a lot* and there is never a time I didn't wish it was built into str instead. Once upon a time all the useful str methods were functions in the string module. I don't think we should be re-introducing that annoyance. [...]
And how do we decide if they are poorly named, given that it's *very* hard to get real-world usage experience for a core Python change before it's released (essentially no-one uses pre-releases for anything other than testing that the release doesn't break their code).
By common sense. s.xyahezgnfspwq(prefix) s.lt(prefix) s.remove_the_prefix_but_only_if_it_exists_on_the_left(prefix) would all be poorly named. We surely don't need real-world usage experience to know that. Eliminate the obviously bad names, and you're left with names which ought to be at least reasonable.
Note that the proposed name (trim) is IMO "poorly named", because a number of languages in my experience use that name for what Python calls "strip", so there would be continual confusion (for me at least) over which name meant which behaviour...
Well there you go, you've just answered your own question about how to tell if the name is poor. That's why we have this list :-) Personally, I don't mind "ltrim" and "rtrim". We're not obliged to present the precise same method names as other languages, any more than they're obliged to consider Python's names. But since you and some others may be confused, I'm happy to bike-shed alternatives. I especially like: cutprefix, cutsuffix lcut, rcut strip_prefix, strip_suffix but presumably somebody will object to them too :-) We didn't need a lot of real-world experience before deciding on async etc, and the disruption risked by adding new keywords is *much* more serious than adding a couple of string methods. [...]
OTOH, it's a new feature, so it won't be acceptable for backporting.
Indeed. I'm not sure why we're talking about backporting. It isn't going to happen, so let's just move on. -- Steven