[Python-ideas] New explicit methods to trim strings

Paul Moore p.f.moore at gmail.com
Sat Mar 30 07:40:18 EDT 2019

On Sat, 30 Mar 2019 at 10:29, Alex Grigoryev <evrial at gmail.com> wrote:

> To me this is really surprising that 28 years old language has some weird
> methods like str.swapcase(), but none to cut string from left or right, and
> two of them which exist only accept string mask.

As someone who was programming 28 years ago, I can confirm that the things
that were "obviously useful" that long ago are vastly different from the
things that are "obviously useful" today. Requirements evolve, use cases
evolve, languages evolve. The good thing about general purpose languages
like Python (as opposed to languages like SQL, which I use in my day job)
is that you can easily handle new requirements by writing your own
functions and utilities, which takes the pressure off the language design
to keep up with every change in requirements and trends. The bad thing
about it is that it's sometimes difficult to distinguish between
significant improvements (which genuinely warrant language/stdlib changes)
and insignificant ones (which can be handled by "write your own function").

Things like str.swapcase are a good example of that experience. It probably
seemed like a useful little function at the time, not much overhead, maybe
useful, people coming from C had something like this and found it helpful,
so why not? But then Unicode came along, and there was a chunk of
maintenance work needed to update swapcase. And there were probably bugs
that got fixed. And as you point out, the function is probably barely ever
used nowadays. So was it worth the effort invested in adding it, and
maintaining it all those years? "It's only a simple addition of a
straightforward string method".

Is str.trim like str.swapcase, or like str.split? Who knows, at this point?
The best any of us with the experience of seeing proposals like this come
up regularly can do, is to push back, make the proposer justify the
suggestion, try to make the proposer consider whether while his idea seems
great right now, will it feel more like str.swapcase in a few years? And
sometimes that pushback *is* too conservative, and an idea is good. But it
still needs someone to implement it, document it, and integrate it into the
language - the proposer isn't always able (or willing) to do that, so again
there's a question of who does the work? In the case of str.swapcase, the
"proposer" was probably the person implementing the str class, and so they
did the work and it was very little extra to do. Nowadays the str class is
a lot more complex, and Unicode rules are far less straightforward than
ASCII was 28 years ago - so maybe now they wouldn't have bothered[1].

Sorry, that went a lot further than I originally intended - hopefully it's
useful background, though.


[1] One thing I don't know (apologies if it's been answered earlier in the
thread). Are you expecting to implement this change yourself (you'd need to
know C, so it's perfectly OK if the answer is no), and if so, have you
tried to do so? Personally, I don't have any feel for how complex the
proposed new methods would be to implement, but I'd be much more willing to
accept the word of someone who's written the code that it's a "simple
change". How easy it is to implement isn't the whole story (as I mentioned
above) but it is relevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190330/eaa7f1c8/attachment.html>

More information about the Python-ideas mailing list