[Python-Dev] Mixed-type datetime comparisons

Tim Peters tim@zope.com
Sat, 25 Jan 2003 16:14:22 -0500


>> Because they're of no use, and at least timedelta.timetuple()
>> wouldn't even make hallucinogenic sense (a timetuple is in units of
>> days, seconds and microseconds).

[M.-A. Lemburg]
> Yes... I don't see your point :-) (mxDateTime has DateTime and
> DateTimeDelta types; no Time type because it's not needed)
>
> If the name bothers, you why not define a different eye-catcher, e.g.
> datetime.tuple(), time.tuple() and timedelta.tuple() ?! (or whatever
> you prefer)

For what purpose?  What should they do?  Why bother?  If this is about
dealing with mixed-type comparisons, defining senseless methods isn't a
reasonable approach.  datetime.timetuple() made sense for datetime.datetime
objects, and was part of /F's "minimal proposal".  Well, sniffing for
timetuple was a "maybe" there, the actual proposal was that all datetime
types derive from a new basetime class, but IIRC you didn't want that.  The
proposal isn't clear to me on this point, but it didn't seem to address pure
time-of-day (exclusive of day) or duration/delta types (it mentions the
latter, but didn't say how they were to be identified).

I'm out of time for doing anything else on 2.3's datetime, so I won't
respond to this topic again (sorry, I just don't have time for it).  If you
and /F can agree on a proposal that does makes sense, and it's not too
elaborate, I'll try to make time to add it after the discussion is over.