"M.-A. Lemburg" wrote:
"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 have no problem relying on external libraries.
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 binary footprint of your types, not the standard base class, right? I don't see a problem with that,
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.
What is data roundtrip safety?
I rarely do date-time arithmetic, but I often do date-time-part extraction. I think that mxDateTime is optimized for arithmetic, whereas, I'd prefer a type more focussed on extraction efficiency, and memory usage, and that effciently supports time zones. This is, of course, no knock on mxDateTime. I also want fast comparisons, which I presume mxDateTime provides.