On Wed, Jun 16, 2010 at 7:25 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 16 Jun 2010 11:59:20 +0200 "M.-A. Lemburg" <mal@egenix.com> wrote:
Antoine Pitrou wrote:
On Tue, 15 Jun 2010 23:03:06 -0700 Brett Cannon <brett@python.org> wrote:
I agree with this sentiment. The UNIX timestamp stuff should stay in time, the time tuple stuff should just go, and datetime should be fleshed out to handle all the stuff that is not a direct wrapping around libc. That way people deal with accurate datetimes as well as well understood concepts with UNIX timestamps and datetime objects.
Agreed.
What? We all agree?
I don't :-)
We've done the stdlib reorg already, now it's time to focus on improving what's there, not removing things.
I don't either. :-) I am not proposing to eliminate any functionality. My proposal is primarily driven by the desire to untangle low level circular dependency between time and datetime modules and to clarify the purpose of keeping functionality in time module that duplicates that in datetime. Another part of my proposal is to provide pure python implementation for time module functions in terms of datetime API. This will serve as both executable documentation and best practices guide. (Assuming the best practice is to use datetime module exclusively.) Let me repeat the three step proposal: 1. Create posixtime.py initially containing just "from time import *" 2. Add python implementation of time.* functions to posixtime.py. 3. Rename time module to _posixtime and add time.py with a deprecation warning and "from _posixtime import *". I would not mind keeping time.py indefinitely with or without deprecation warnings.