[Python-ideas] New explicit methods to trim strings

Paul Moore p.f.moore at gmail.com
Sat Mar 30 06:21:23 EDT 2019

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. But OK, let's stick to the points you want to
make here.

>> > We are balancing equities here.  We have a plethora of changes, on the
>> one side taken by itself each of which is an improvement, but on the
>> other taken as a group they greatly increase the difficulty of
>> learning to read Python programs fluently.
> Unless the methods are really poorly named, then this will make them maybe a tiny bit more readable, not less. But tiny. So “irrelevant” may be appropriate here.

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

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...

>> So we set a bar that the
>> change must clear, and the ability of the change to clear it depends
>> on the balance of equities.
> Exactly — small impact, low bar.

If we accept your statement that it's a small impact. I contend that
the confusion that this would cause between strip and trim is not
small. It's not *huge*, but it's not small... We can agree to differ,
but if we do then don't expect me to agree to your statement that the
bar can be low, you need to persuade me to agree that the impact is
low if you want me to agree on the matter of the bar.

>> In this case, where it requires C support and is not possible to "from
>> __future__", the fact that library maintainers can't use it until they
>> drop support for past versions of Python weakens the argument for the
>> change by excluding important bodies of code from using it.
> But there is no need for __future__ — it’s not a breaking change. It could be back ported to any version we want. Same as a __future__ import.

OTOH, it's a new feature, so it won't be acceptable for backporting.
Sorry, but those are the rules. What "we" want isn't relevant here,
unless the "we" in question is the Python core devs, and the core devs
have established the "no backports of new features" rule over many
years, and won't be likely to change it for something that you
yourself are describing as "small impact".


More information about the Python-ideas mailing list