All of this would be well served by a 3rd party library on PyPI. Strings already have plenty of methods (probably too many). Having `stringtools` would be nice to import a bunch of simple functions from.
I respectfully disagree. This isn't javascript where we are OK with millions of tiny dependencies. Python is batteries included and that's a great thing. This is just a tiny battery that was overlooked :)
While batteries included is a very good principle (and one I've argued for strongly in the past) it's also important to remember that Python is a mature language, and the days of being able to assume that "most people" will be on a recent version are gone.
It's much more true now than it has been in over a decade. People have largely moved away from python 2.7 and after that it's pretty easy to keep pace. There's a lag, but it's no longer decades.
Adding these functions to the stdlib would mean that *only* people using Python 3.8+ would have access to them (and in particular, library authors wouldn't be able to use them until they drop support for all versions older than 3.8). Having the functions as an external library makes them accessible to *every* Python user.
Sure. And if library authors want to support older versions they'll have to vendor this into their own code, 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.
As with everything, it's a trade-off. IMO, in this case the balance is in favour of a 3rd party library (at least initially - it's perfectly possible to move the library into the stdlib later if it becomes popular).
Putting it in a library virtually guarantees it will never become popular. 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. Plus it's actually impossible:
str.foo = 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't set attributes of built-in/extension type 'str'
So this can't really be moved into the standard library or be implemented by a library in a nice way. / Anders