[Python-ideas] New explicit methods to trim strings

Stephen J. Turnbull turnbull.stephen.fw at u.tsukuba.ac.jp
Thu Mar 28 23:06:25 EDT 2019

Anders Hovmöller writes:

 > Sure. And if library authors want to support older versions they'll
 > have to vendor this into their own code,

You (indirectly) argue below that they can't, as a reason for including
the change.  You can't have it both ways.

 > just like always. This seems totally irrelevant to the
 > discussion. And it's of course irrelevant to all the end users that
 > aren't writing libraries but are using python directly.

No, it's not "irrelevant".  I wish we all would stop using that word,
and trying to exclude others' arguments in this way.

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

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.

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

Factually, you're wrong.  Many libraries have moved from PyPI to the
stdlib, often very quickly as they prove their worth in a deliberate
test.  Also, here "popular" has a special meaning.  It doesn't mean
millions of downloads.  It means people say they like it in blogs,
recommend it to others, and start to post to Python development
channels saying how much it improves their code and posting examples
of how it does so.

 > And because we are talking about new methods on str, a
 > library that monkey patches on two new method on str won't become
 > popular for obvious reasons [specifically, it's impossible].

This is a valid point.  But it doesn't need to be a monkey patch.
Note that decimal was introduced with no literal syntax and is quite
useful and used.  If this change is going to prove it's tall enough to
ride the stdlib ride, using a constructor for a derived class rather
than str literal syntax shouldn't be too big a barrier to judging
popularity (accounting for the annoyance of a constructor).
Alternatively, the features could be introduced using functions.


More information about the Python-ideas mailing list