[Hamish Lawson] > One of the arguments put forward against renaming the existing time > module to _time (as part of incorporating a pure-Python strptime > function) is that it could break some builds. Therefore I'd suggest > that it could be a useful principle for any C extension added in the > future to the standard library to have an accompanying pure-Python > wrapper that would be the one that client code would usually import. There are too many distinct use cases to make this a hard and fast rule. The problem with maintaining many builds is best served by keeping the number of extensions small, period. [Marc-Andre Lemburg] > BTW, this reminds me of the old idea to move that standard > lib into a package, eg. 'python'... > > from python import time. Maybe in Python 3000. In 2.x, I think rearranging the standard library will just cause more upheaval without much benefits. > We should at least reserve such a name RSN so that we don't > run into problems later on. I can guarantee you that that name won't be used as a standard Python module or package name any time soon. If someone creates a 3rd party package or module named 'python' I'd question their sanity. :-) --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