[Neil Schemenauer] > Can you explain the logic behind this recent interest in removing > string functions from the standard library? It it performance? > Some unicode issue? I don't have a great attachment to string.py > but I also don't see the justification for the amount of work it > requires. [Guido] > I figure that at *some* point we should start putting our money where > our mouth is, deprecate most uses of the string module, and start > warning about it. Not in 2.1 probably, given my experience below. I think this begs Neil's questions: *is* our mouth there <ahem>, and if so, why? The only public notice of impending string module deprecation anyone came up with was a vague note on the 1.6 web page, and one not repeated in any of the 2.0 release material. "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. > As a realistic test of the warnings module I played with some warnings > about the string module, and then found that say most of the std > library modules use it, triggering an extraordinary amount of > warnings. I then decided to experiment with the conversion. I > quickly found out it's too much work to do manually, so I'll hold off > until someone comes up with a tool that does 99% of the work. Ah, so that's the *easy* way to kill this crusade -- forget I said anything <wink>.
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