Could we try to keep the discussion about the topic at hand? There are a broad set if considerations that apply to any change, but they don’t all apply equally to all proposals.

The proposal at hand is to add two fairly straightforward methods to string. So:

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

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.

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.

 > Putting it in a library virtually guarantees it will never become
 > popular.

Factually, you're wrong.


I don’t think he is, and I made the same point earlier. He did not say that no PyPi libs become popular or are brought into the stdlib, He said that this particular proposal is not suited to that. Do you really think a lib with two (or a few, though no one yet has suggested anymore) almost trivial string functions will gain any traction??


Note that decimal was introduced with no literal syntax and is quite
useful and used.

But Decimal isn’t a float with a couple extra handy methods. If it didn’t provide significant extra functionality, no one would use it. 

And many strings in our code are created from other code — so then you’d need to wrap MySpecialString() around every function call that produced a string. 

Again— it’s not going to happen.

Alternatively, the features could be introduced using functions.

Better than a custom class, but still too awkward to bother with for this — see a previous post of mine for more detail.

This proposal would provide a minor gain for an even more minor disruption.

-CHB
--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython