Let's not redesign the time module API too much. I'm all for adding the default argument values that Thomas proposes. Then, instead of changing the API, we should look into a higher-level Python module. That's how those things typically go. Digital Creations has its own time extension type somewhere in Zope, a bit similar to mxDateTime. I looked into making this a standard Python extension but quickly gave up. The problems with these things seems to be that it's hard to come up with a design that makes everyone happy: some people want small objects (because they have a lot of them around, e.g. a timestamp on almost every other object); others want timezone support; yet others want microsecond resolution; leap-second support; pre-Christian era support; support for nonstandard calendars; interval arithmetic; support for dates without times or times without dates... Python could use a better time type, but we'll have to look into which requirements make sense for a generalized type, and which don't. I fear that a committee could easily pee away years designing an interface to satisfy absolutely every wish. --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