As a longstanding Python advocate and user, I find this thread disturbing, and feel compelled to add a few words: > > [Tim wrote:] > > "string" is right up there with "os" and "sys" as a FIM (Frequently > > Imported Module), so the required code changes will be massive. As > > a user, I don't see what's in it for me to endure that pain: the > > string module functions work fine! Neither are they warts in the > > language, any more than that we say sin(pi) instead of pi.sin(). > > Keeping the functions around doesn't hurt anybody that I can see. > > [Guido wrote:] > Hm. I'm not saying that this one will be easy. But I don't like > having "two ways to do it". It means more learning, etc. (you know > the drill). But with all due respect, there are already _lots_ of places in Python that provide at least two ways to do something already. Why be so strict on this one alone? Consider lambda and def; tuples and lists; map and for loops; the loop else and boolean exit flags; and so on. The notion of Python forcing a single solution is largely a myth. And as someone who makes a living teaching this stuff, I can tell you that none of the existing redundancies prevent anyone from learning Python. More to the point, many of those shiny new features added to 2.0 fall squarely into this category too, and are completely redundant with other tools. Consider list comprehensions and simple loops; extended print statements and sys.std* assignments; augmented assignment statements and simpler ones. Eliminating redundancy at a time when we're also busy introducing it seems a tough goal to sell. I understand the virtues of aesthetics too, but removing the string module seems an incredibly arbitrary application of it. > If you're saying that you think the string module is too prominent to > ever start deprecating its use, I'm afraid we have a problem. > > [...] > Ideally, I'd like to deprecate the entire string module, so that I > can place a single warning at its top. This will cause a single > warning to be issued for programs that still use it (no matter how > many times it is imported). And to me, this seems the real crux of the matter. For a decade now, the string module _has_ been the right way to do it. And today, half a million Python developers absolutely rely on it as an essential staple in their toolbox. What could possibly be wrong with keeping it around for backward compatibility, albeit as a less recommended option? If almost every Python program ever written suddenly starts issuing warning messages, then I think we do have a problem indeed. Frankly, a Python that changes without regard to its user base seems an ominous thing to me. And keep in mind that I like Python; others will look much less generously upon a tool that seems inclined to rip the rug out from under its users. Trust me on this; I've already heard the rumblings out there. So please: can we keep string around? Like it or not, we're way past the point of removing such core modules at this point. Such a radical change might pass in a future non-backward- compatible Python mutation; I'm not sure such a different system will still be "Python", but that's a topic for another day. All IMHO, of course, --Mark Lutz (http://www.rmi.net~lutz)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4