Guido van Rossum wrote: > > > > The timetuple() method provides access to all of these > > > simultaneously. Isn't that enough? > > > > From a minimalist point of view, yet, but from a usability point > > of view, no. > > > > > t.year() could be spelled as > > > t.timetuple()[0]. > > > > Yes, but t.year() is a lot more readable. > > When do you ever use this in isolation? I'd expect in 99% of the > cases you hand it off to a formatting routine, and guess what -- > strftime() takes a time tuple. > > I worry about the time wasted by calling all of t.year(), t.month(), > t.day() (etc.) -- given that they do so little, the call overhead is > probably near 100%. > > I wonder how often this is needed. The only occurrences of year() in > the entire Zope source that I found are in various test routines. These methods and others are used a lot in presentation code, which tends to be expressed in DTML or ZPT. It's not uncommon to select/catagorize things by year or month. I think most people would find individual date-part methods a lot more natural than tuples. > > > I expect that usually you'd request several of > > > these together anyway, in order to do some fancy formatting, so the > > > timetuple() approach makes sense. > > > > I find the time tuples to be really inconvenient. I *always* > > have to slice off the parts I don't want, which I find annoying. > > Serious question: what do you tend to do with time values? I format them in various ways and I sort them. > I imagine > that once we change strftime() to accept an abstract time object, > you'll never need to call either timetuple() or year() -- strftime() > will do it for you. Maybe, if I use strftime, but I don't use strftime all that much. I can certainly think of even formatting cases (e.g. internationalized dates) where it's not adequate. > > Hm, now that I mention the extra parts, it seems kind of silly > > to make implementors of the type come up with weekday, julian day, and > > a daylight-savings flag. This time format is really biased by > > the C time library, which is fine for a module that wraps the C library > > but seems a bit silly for a standard date-time interface. > > That's why /F's pre-PEP allows the implementation to leaves these > three set to -1. I missed these. Still, providing -1s seems, uh, vestigial. > > > > with date parts > > > > being one based and time parts being zero based. > > > > > > I'm not sure what you mean here. > > > > Years, months, and days should start from 1. > > Hours, minutes and seconds should start from 0. > > > > One confusion I often have with time tuples is that I know > > too much about C's time struct, which numbers months from 0 > > and which has years since 1900. > > I guess that confusion is yours alone. In Python, of course month and > day start from 1. Whether years start from 1 is a theological > question. :-) I doubt the confusion is mine alone, but I'll take your word for it. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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