[Python-ideas] New explicit methods to trim strings

[Steven D'Aprano]

On Sat, Mar 30, 2019 at 10:21:23AM +0000, Paul Moore wrote:
> On Fri, 29 Mar 2019 at 23:07, Christopher Barker <pythonchb at 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