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

code).

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

Paul

_______________________________________________

Python-ideas mailing list

Python-ideas@python.org

https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct: http://python.org/psf/codeofconduct/