[Python-ideas] New explicit methods to trim strings
steve at pearwood.info
Sat Mar 30 08:14:39 EDT 2019
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
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
By common sense.
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
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.
More information about the Python-ideas