> "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. 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). We could have chosen to make the strop module support Unicode; instead, we chose to give string objects methods and promote the use of those methods instead of the string module. (And in a generous mood, we also supported Unicode in the string module -- by providing wrappers that invoke string methods.) If you're saying that we should give users ample time for the transition, I'm with you. 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. I'd also like to note that using the string module's wrappers incurs the overhead of a Python function call -- using string methods is faster. Finally, I like the look of fields[i].strip().lower() much better than that of string.lower(string.strip(fields[i])) -- an actual example from mimetools.py. Ideally, I would 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). Unfortunately, there are a couple of things that still need it: string.letters etc., and string.maketrans(). --Guido van Rossum (home page: http://www.python.org/~guido/)
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