>> 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.
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