Tim Peters wrote: > [TIm] > >>Note that this doesn't help for mixed-type time or timedelta comparison: >>datetime's time and timedelta objects don't have timetuple methods >>themselves, and their comparison implementations still raise TypeError >>whenever they don't recognize the other comparand's type (this >>is needed to prevent comparison against objects of arbitrary types from >>falling back to the default comparison of object addresses). > > > [M.-A. Lemburg] > >>Why not add them (setting the date parts to None) ? > > 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). 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) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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