"Fred L. Drake, Jr." wrote:
Guido van Rossum writes:
Is comparison the same what Tim mentioned as range searches? I guess a representation like current Zope timestamps or what time.time() returns is fine for that -- it is monononous even if not necessarily continuous. I guess a broken-out time tuple is much harder to compare.
Yes; as long as ordering is easy to check, we're fine with a long int or some such thing. The range search is indeed the specific application Jim has in mind.
Uhm... I think this thread is heading in the wrong direction.
Fredrik wasn't proposing a solution to Jim's particular problem (whatever it was ;-), but instead opting for a solution of a large number of Python users out there.
While mxDateTime probably works for most of them (and is used by pretty much all major database modules out there), some may feel that they don't want to rely on external libs for their software to run on.
I would be willing to make the mxDateTime types subtypes of whatever Fredrik comes up with. The only requirement I have is that the binary footprint of the types needs to match todays layout of mxDateTime types since I need to maintain binary compatibility.
The other possibility would be adding a set of new types to mxDateTime which focus on low memory requirements rather than data roundtrip safety and speed.
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH