Guido van Rossum wrote:
[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.
I don't think the mistake was so much to store broken-out info, but to store too much data in general. It stores redundant data, which makes it's implementation a bit difficult to understand and maintain. Note that scalability was not a goal of Zope's DateTime type. We meant to replace it with something much tighter a long time ago, but never got around to it.
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.
Yup.
I'll show the PEP to Jim when it appears.
Thanks. ;) BTW, has there been any progress on this? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org