Guido van Rossum wrote: > > [me] > > > 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. > > [Jim] > > 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. > > OK, that explains a lot. For this context I agree, although I think > they should probably appear as (computed) attributes rather than > methods. Properties seem perfect. That's fine with me. > > > 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. > > Maybe you should. :-) I do when I can. But it often doesn't meet my needs. > > I can certainly think of even formatting cases (e.g. internationalized > > dates) where it's not adequate. > > Then a super-strftime() should be invented that *is* enough, rather > than fumbling with hand-coded solutions. I think we don't need a one-size-fits-all all-powerful date-time formating solution. ;) 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