A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-February/020402.html below:

add basic time type to the standard library

[Python-Dev] proposal: add basic time type to the standard library [Python-Dev] proposal: add basic time type to the standard libraryGuido van Rossum guido@python.org
Tue, 26 Feb 2002 16:37:31 -0500
[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.

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

--Guido van Rossum (home page: http://www.python.org/~guido/)



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