[Tim] > Are you sure Jim is looking to replace the TimeStamp object? All the > complaints I've seen aren't about the relatively tiny TimeStamp object, but > about Zope's relatively huge DateTime class (note that you won't have source > for that if you're looking at a StandaloneZODB checkout -- DateTime is used > at higher Zope levels), which is a Python class with a couple dozen(!) > instance attributes. See, e.g., > > http://dev.zope.org/Wikis/DevSite/Proposals/ReplacingDateTime > > It seems clear from the source code that TimeStamp is exactly what Jim > intended it to be <wink>. I'm notoriously bad at channeling Jim. Nevertheless, I do recall him saying he wanted a lightweight time object. I think the mistake of DateTime is that it stores the broken-out info, rather than computing it on request. > > Your idea of a base type (which presumably standarizes at least one > > form of representation) sounds like a breakthrough that can help > > satisfy different other needs. > > Best I can make out, /F is only proposing what Jim would call an Interface: > the existence of two methods, timetuple() and utctimetuple(). In a comment > on his page, /F calls it an "abstract" base class, which is more C++-ish > terminology, and the sample implementation makes clear it's a "pure" > abstract base class, so same thing as a Jim Interface in the end. I'll show the PEP to Jim when it appears. --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