[Python-ideas] Rename time module to "posixtime"

Cameron Simpson cs at zip.com.au
Fri Jun 18 00:50:28 CEST 2010

On 16Jun2010 10:37, Brett Cannon <brett at python.org> wrote:
| On Wed, Jun 16, 2010 at 00:56, M.-A. Lemburg <mal at egenix.com> wrote:
| > Brett Cannon wrote:
| >> On Tue, Jun 15, 2010 at 16:01, Cameron Simpson <cs at zip.com.au> wrote:
| >>> On 15Jun2010 10:47, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
| >>> | I've reread my post and have to admit that I did not explain this
| >>> | point clearly.  There are currently three different ways to represent
| >>> | a point in time: datetime object, unix timestamp, and a 9-element time
| >>> | tuple.  While the datetime module has its share of criticism, its
| >>> | interfaces are more user friendly and more "pythonic" than C inspired
| >>> | time module interfaces.
| >>>
| >>> Personally, I would be happy to see unix-timestamp and datetime object,
| >>> and see the time tuples go away.
| >> 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.
| > -1.
| > Please note that the time module provides access to low-level OS
| > provided services which the datetime module does not expose.
| > You cannot seriously expect that an application which happily uses
| > the time module (only) for its limited date/time functionality
| > to have to be rewritten just to stay compatible with Python.
| No, but the work to move people off of time tuples and over to
| datetime objects or timestamps can start so that the next stdlib reorg
| can drop time tuples without causing major pains.

"I agree with this sentiment." :-)

I, also, was insufficiently clear. I don't want any code to break, and
Alexander's proposal describes a non-breaking approach. I would like my
earlier statement to be read as wanting it to be possible to work with
unixtimes and datetimes and never need to use a time tuple, and for the
documentation to direct users to datetimes and unixtimes as the obvious
and sufficent way to do things.

| I don't care as much about the rename as I do about losing time tuples
| in the long run.
| > The only improvement I could see, would be to move
| > calendar.timegm() to the time module, since that's where
| > it belongs (keeping an alias in the calendar module, of
| > course).
| That should definitely happen at some point.

+1 to the above too. That the "Use the following functions to convert
between time representations" table near the top of the "time" module
documentation reaches for the calendar module grates.

Cameron Simpson <cs at zip.com.au> DoD#743

In any event, this is a straw herring for debate.
        - solovay at netcom.com (Andrew Solovay)

More information about the Python-ideas mailing list