As someone who was programming 28 years ago, I can confirm that the things that were "obviously useful" that long ago are vastly different from the things that are "obviously useful" today. Requirements evolve, use cases evolve, languages evolve. The good thing about general purpose languages like Python (as opposed to languages like SQL, which I use in my day job) is that you can easily handle new requirements by writing your own functions and utilities, which takes the pressure off the language design to keep up with every change in requirements and trends. The bad thing about it is that it's sometimes difficult to distinguish between significant improvements (which genuinely warrant language/stdlib changes) and insignificant ones (which can be handled by "write your own function").

Things like str.swapcase are a good example of that experience. It probably seemed like a useful little function at the time, not much overhead, maybe useful, people coming from C had something like this and found it helpful, so why not? But then Unicode came along, and there was a chunk of maintenance work needed to update swapcase. And there were probably bugs that got fixed. And as you point out, the function is probably barely ever used nowadays. So was it worth the effort invested in adding it, and maintaining it all those years? "It's only a simple addition of a straightforward string method".

Is str.trim like str.swapcase, or like str.split? Who knows, at this point? The best any of us with the experience of seeing proposals like this come up regularly can do, is to push back, make the proposer justify the suggestion, try to make the proposer consider whether while his idea seems great right now, will it feel more like str.swapcase in a few years? And sometimes that pushback *is* too conservative, and an idea is good. But it still needs someone to implement it, document it, and integrate it into the language - the proposer isn't always able (or willing) to do that, so again there's a question of who does the work? In the case of str.swapcase, the "proposer" was probably the person implementing the str class, and so they did the work and it was very little extra to do. Nowadays the str class is a lot more complex, and Unicode rules are far less straightforward than ASCII was 28 years ago - so maybe now they wouldn't have bothered[1].

Sorry, that went a lot further than I originally intended - hopefully it's useful background, though.

Paul

[1] One thing I don't know (apologies if it's been answered earlier in the thread). Are you expecting to implement this change yourself (you'd need to know C, so it's perfectly OK if the answer is no), and if so, have you tried to do so? Personally, I don't have any feel for how complex the proposed new methods would be to implement, but I'd be much more willing to accept the word of someone who's written the code that it's a "simple change". How easy it is to implement isn't the whole story (as I mentioned above) but it is relevant.