Rename time module to "posixtime"

One of the common complains about working with time values in Python, is that it some functionality is available in time module, some in datetime module and some in both. I propose a series of steps towards improving this situation. 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 *". Note that #2 may require to move some code from timemodule.c to datetimemodule.c, but at the binary level code compiled from these files is already linked together in datetimemodule. Moving the necessary code to datetime.c will help to eliminate current circular dependency between time and datetime.

Alexander Belopolsky wrote:
I'm not sure I understand the point in renaming the module. Note that the time module works based on Unix ticks (seconds since the Unix Epoch), while the datetime module works based on its own set of types. As such, the two are different implementations for managing date/time. Mixing them won't make things easier to understand. The time module is very close to the C lib API, while the datetime module focuses more on date/time storage in a more accessible. I agree on one point, though: the shared C APIs for getting the current time would be better put into a separate C extension which both can then load without creating circular references, e.g. _getcurrenttime.c. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 15 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 33 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg <mal@egenix.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. For example,
print(datetime.now())
is self-explainatory but
time.time() 1276609479.559051
requires a lot of explaining even to people with C/POSIX background. For the later, the immediate questions would be why the output is a float and what is the precision of the result. For people without C background, time module interfaces are cryptic and arbitrary. Why time() produces a float while localtime() produces a tuple? Why asctime takes tuple while ctime takes float? Conversions between timestamp/timetuple and datetime are quite awkward as well. We have datetime.timetuple(), but no fromtimetuple() (you have to write cryptic datetime(*tt[:6]). With timestamps, it is the opposite. We have a full compliment of fromtimestamp/utcfromtimestamp, but no functions to go in the opposite direction. Finally, we have a 3-way name conflict: time is a module, a function and a type. I believe most of applications are better off using datetime module exclusively. The time module should be used for interoperability with POSIX interfaces, but not for general date/time manipulations. Renaming the module will make its name match its purpose better.
I certainly know that. What some people don't understand, though is that translation between Unix ticks (or more accurately POSIX time_t value) and broken down UTC time is just an arithmetic operation. The formula is convoluted, but it is just a formula independent of any system databases. There is no good reason for a python application to keep time values as POSIX timestamps rather than datetime objects. The correspondence between the two is one to one, the ordering is the same and arithmetics is cleaner with datetime because it is explicit about (decimal) precision.
I am not proposing mixing them. To the contrary, I want to make it clearer that users should not mix them: use posixtime module if you need to interoperate with posix interfaces and datetime for everything else.
What I would like to do is to expose POSIX gettimeofday interface as both C API and python function returning (seconds, microseconds) tuple. In my view, C implementation should go to _posixtimemodule.c and posixtime.py should have def gettimeofday(): q, r = divmod(datetime.utcnow() - datetime(1970,1,1), timedelta(seconds=1)) return q, r.microseconds

On 15Jun2010 10:47, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote: | On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg <mal@egenix.com> wrote: | > Alexander Belopolsky wrote: | >> One of the common complains about working with time values in Python, | >> is that it some functionality is available in time module, some in | >> datetime module and some in both. | .. | > I'm not sure I understand the point in renaming the module. | | 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. The tuples are a direct mirror of the unix "struct tm" structures and and should really only be visible in a "posixtime" module of some kind - the datetime objects are their direct equivalents anyway to my mind and should be what are dealt with for human calendar stuff. However, the unix timestamps should stay (or anything equivalent that measures real world seconds, but since any epoch will do for that purpose and we've got the unix one in use I'd stay with it). They represent an absolute timeframe and let one do direct arithmetic. If I'm not doing calendar things (or only doing them for presentation) then the unix timestamp is usually my preferred time item. | Conversions between timestamp/timetuple and datetime are quite awkward | as well. We have datetime.timetuple(), but no fromtimetuple() (you | have to write cryptic datetime(*tt[:6]). With timestamps, it is the | opposite. We have a full compliment of | fromtimestamp/utcfromtimestamp, but no functions to go in the opposite | direction. Yes, awful. Having spent a fair chunk of yesterday trying to obtain an adapter (or chain of adapters) to join a 3G modem to an antenna with a different end, I feel your pain. And I've felt it with the time functions too. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ A man with one watch knows what time it is; a man with two watches is never sure. - Lee Segall

On Tue, Jun 15, 2010 at 16:01, Cameron Simpson <cs@zip.com.au> 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. Time tuples are just not accurate enough. Datetime objects can keep the ability to export and import from time tuples for extensions that need to interface with 'struct tm' code, but otherwise it should be considered a lossy datetime encoding that we do not really support else we are going to constantly be trying to fix the time tuple to be more accurate when it was simply just not well designed.

Brett Cannon wrote:
-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. Note that not all applications are interested in sub-second accuracy and a computer without properly configured NTP and good internal clock doesn't even provide this accuracy to begin with (even if they happily pretend they do by exposing sub-second floats). You might want to do that for Python4 and then add all those time module functions using struct_time to the datetime module (returning datetime instances), but for Python3, we've had the stdlib reorg already. Renaming time -> posixtime falls into the same category. 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). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Wed, Jun 16, 2010 at 00:56, M.-A. Lemburg <mal@egenix.com> wrote:
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 don't care as much about the rename as I do about losing time tuples in the long run.
That should definitely happen at some point.

On 16Jun2010 10:37, Brett Cannon <brett@python.org> wrote: | On Wed, Jun 16, 2010 at 00:56, M.-A. Lemburg <mal@egenix.com> wrote: | > Brett Cannon wrote: | >> On Tue, Jun 15, 2010 at 16:01, Cameron Simpson <cs@zip.com.au> wrote: | >>> On 15Jun2010 10:47, Alexander Belopolsky <alexander.belopolsky@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. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ In any event, this is a straw herring for debate. - solovay@netcom.com (Andrew Solovay)

Antoine Pitrou wrote:
I don't :-) We've done the stdlib reorg already, now it's time to focus on improving what's there, not removing things. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 16 June 2010 10:59, M.-A. Lemburg <mal@egenix.com> wrote:
The standard library will continue to evolve in Python 3 though, with both additions and deprecations - following our standard deprecation policy of course. Michael

On Wed, 16 Jun 2010 11:59:20 +0200 "M.-A. Lemburg" <mal@egenix.com> wrote:
Well, I agree that adding functionality is what's mostly needed in the date/time area right now. Removing old stuff should be quite low priority compared to that. (perhaps I should stop agreeing with everyone, sorry :-)) Regards Antoine.

On Wed, Jun 16, 2010 at 7:25 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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.

On Wed, Jun 16, 2010 at 09:44:59AM -0400, Alexander Belopolsky wrote:
This is a clear idea you are having for datetime + (possibly a) pure python posixtime module. The reference implementation as well as documentation will definitely be beneficial in the long run. So, +1 for your proposal.
I would not mind keeping time.py indefinitely with or without deprecation warnings.
Yeah, this would ensure the backwards compatibility. -- Senthil Have a place for everything and keep the thing somewhere else; this is not advice, it is merely custom. -- Mark Twain

Terry Reedy wrote:
Agreed. It would be useful to add a note to the time module docs pointing newbies directly to the datetime module. For experts, the time module is still very useful to have around. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Thu, Jun 17, 2010 at 6:31 AM, M.-A. Lemburg <mal@egenix.com> wrote:
For myself, I think a long term plan (i.e. Py4k'ish) to move to a _posixtime/posixtime C/Python hybrid implementation for the POSIX timestamp manipulation would be beneficial. Largely, as Alexander points out, to make the distinction between the time module, the time.time function and datetime.time objects significantly clearer than it is now:
We can at least cut down the naming conflict to only exist between the latter two items. Such a transition could be made in the documentation (with a note in the "posixtime" documentation to say that it remains available as the time module for backwards compatibility reasons) as early as 3.2. Of course, any functionality gaps identified in datetime would still need to be closed. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Mon, 14 Jun 2010 20:09:02 -0400 Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Is it a common complaint, really? The common complaint, IMO, is that *none* of those two modules provides a complete feature set in itself.
I don't understand the purpose. I certainly like time.time() and I don't see the point of making it go away (will we have to use one of these "obvious" datetime-based one-liners instead?). Regards Antoine.

Le 15/06/2010 12:16, Antoine Pitrou a écrit :
The fact that we need dateutil or pytz to do some calculations is not optimal but it’s another concern. I agree that the overlap between time, datetime and calendar is annoying. More specifically, the multitude of types is bad (integer timestamp, time tuple, datetime object). Some bad one-liners that use some datetimes methods with unpacked (*arg) time tuples coming from another datetime method scream “shenanigans” to me.
time.time will still be available, just under another name that makes it clear it’s a binding to a low-level C concept. A user vote: +1 on renaming, +1 on improving datetime. Regards

Alexander Belopolsky wrote:
I'm not sure I understand the point in renaming the module. Note that the time module works based on Unix ticks (seconds since the Unix Epoch), while the datetime module works based on its own set of types. As such, the two are different implementations for managing date/time. Mixing them won't make things easier to understand. The time module is very close to the C lib API, while the datetime module focuses more on date/time storage in a more accessible. I agree on one point, though: the shared C APIs for getting the current time would be better put into a separate C extension which both can then load without creating circular references, e.g. _getcurrenttime.c. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 15 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 33 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg <mal@egenix.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. For example,
print(datetime.now())
is self-explainatory but
time.time() 1276609479.559051
requires a lot of explaining even to people with C/POSIX background. For the later, the immediate questions would be why the output is a float and what is the precision of the result. For people without C background, time module interfaces are cryptic and arbitrary. Why time() produces a float while localtime() produces a tuple? Why asctime takes tuple while ctime takes float? Conversions between timestamp/timetuple and datetime are quite awkward as well. We have datetime.timetuple(), but no fromtimetuple() (you have to write cryptic datetime(*tt[:6]). With timestamps, it is the opposite. We have a full compliment of fromtimestamp/utcfromtimestamp, but no functions to go in the opposite direction. Finally, we have a 3-way name conflict: time is a module, a function and a type. I believe most of applications are better off using datetime module exclusively. The time module should be used for interoperability with POSIX interfaces, but not for general date/time manipulations. Renaming the module will make its name match its purpose better.
I certainly know that. What some people don't understand, though is that translation between Unix ticks (or more accurately POSIX time_t value) and broken down UTC time is just an arithmetic operation. The formula is convoluted, but it is just a formula independent of any system databases. There is no good reason for a python application to keep time values as POSIX timestamps rather than datetime objects. The correspondence between the two is one to one, the ordering is the same and arithmetics is cleaner with datetime because it is explicit about (decimal) precision.
I am not proposing mixing them. To the contrary, I want to make it clearer that users should not mix them: use posixtime module if you need to interoperate with posix interfaces and datetime for everything else.
What I would like to do is to expose POSIX gettimeofday interface as both C API and python function returning (seconds, microseconds) tuple. In my view, C implementation should go to _posixtimemodule.c and posixtime.py should have def gettimeofday(): q, r = divmod(datetime.utcnow() - datetime(1970,1,1), timedelta(seconds=1)) return q, r.microseconds

On 15Jun2010 10:47, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote: | On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg <mal@egenix.com> wrote: | > Alexander Belopolsky wrote: | >> One of the common complains about working with time values in Python, | >> is that it some functionality is available in time module, some in | >> datetime module and some in both. | .. | > I'm not sure I understand the point in renaming the module. | | 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. The tuples are a direct mirror of the unix "struct tm" structures and and should really only be visible in a "posixtime" module of some kind - the datetime objects are their direct equivalents anyway to my mind and should be what are dealt with for human calendar stuff. However, the unix timestamps should stay (or anything equivalent that measures real world seconds, but since any epoch will do for that purpose and we've got the unix one in use I'd stay with it). They represent an absolute timeframe and let one do direct arithmetic. If I'm not doing calendar things (or only doing them for presentation) then the unix timestamp is usually my preferred time item. | Conversions between timestamp/timetuple and datetime are quite awkward | as well. We have datetime.timetuple(), but no fromtimetuple() (you | have to write cryptic datetime(*tt[:6]). With timestamps, it is the | opposite. We have a full compliment of | fromtimestamp/utcfromtimestamp, but no functions to go in the opposite | direction. Yes, awful. Having spent a fair chunk of yesterday trying to obtain an adapter (or chain of adapters) to join a 3G modem to an antenna with a different end, I feel your pain. And I've felt it with the time functions too. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ A man with one watch knows what time it is; a man with two watches is never sure. - Lee Segall

On Tue, Jun 15, 2010 at 16:01, Cameron Simpson <cs@zip.com.au> 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. Time tuples are just not accurate enough. Datetime objects can keep the ability to export and import from time tuples for extensions that need to interface with 'struct tm' code, but otherwise it should be considered a lossy datetime encoding that we do not really support else we are going to constantly be trying to fix the time tuple to be more accurate when it was simply just not well designed.

Brett Cannon wrote:
-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. Note that not all applications are interested in sub-second accuracy and a computer without properly configured NTP and good internal clock doesn't even provide this accuracy to begin with (even if they happily pretend they do by exposing sub-second floats). You might want to do that for Python4 and then add all those time module functions using struct_time to the datetime module (returning datetime instances), but for Python3, we've had the stdlib reorg already. Renaming time -> posixtime falls into the same category. 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). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Wed, Jun 16, 2010 at 00:56, M.-A. Lemburg <mal@egenix.com> wrote:
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 don't care as much about the rename as I do about losing time tuples in the long run.
That should definitely happen at some point.

On 16Jun2010 10:37, Brett Cannon <brett@python.org> wrote: | On Wed, Jun 16, 2010 at 00:56, M.-A. Lemburg <mal@egenix.com> wrote: | > Brett Cannon wrote: | >> On Tue, Jun 15, 2010 at 16:01, Cameron Simpson <cs@zip.com.au> wrote: | >>> On 15Jun2010 10:47, Alexander Belopolsky <alexander.belopolsky@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. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ In any event, this is a straw herring for debate. - solovay@netcom.com (Andrew Solovay)

Antoine Pitrou wrote:
I don't :-) We've done the stdlib reorg already, now it's time to focus on improving what's there, not removing things. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 16 June 2010 10:59, M.-A. Lemburg <mal@egenix.com> wrote:
The standard library will continue to evolve in Python 3 though, with both additions and deprecations - following our standard deprecation policy of course. Michael

On Wed, 16 Jun 2010 11:59:20 +0200 "M.-A. Lemburg" <mal@egenix.com> wrote:
Well, I agree that adding functionality is what's mostly needed in the date/time area right now. Removing old stuff should be quite low priority compared to that. (perhaps I should stop agreeing with everyone, sorry :-)) Regards Antoine.

On Wed, Jun 16, 2010 at 7:25 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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.

On Wed, Jun 16, 2010 at 09:44:59AM -0400, Alexander Belopolsky wrote:
This is a clear idea you are having for datetime + (possibly a) pure python posixtime module. The reference implementation as well as documentation will definitely be beneficial in the long run. So, +1 for your proposal.
I would not mind keeping time.py indefinitely with or without deprecation warnings.
Yeah, this would ensure the backwards compatibility. -- Senthil Have a place for everything and keep the thing somewhere else; this is not advice, it is merely custom. -- Mark Twain

Terry Reedy wrote:
Agreed. It would be useful to add a note to the time module docs pointing newbies directly to the datetime module. For experts, the time module is still very useful to have around. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
2010-07-19: EuroPython 2010, Birmingham, UK 32 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Thu, Jun 17, 2010 at 6:31 AM, M.-A. Lemburg <mal@egenix.com> wrote:
For myself, I think a long term plan (i.e. Py4k'ish) to move to a _posixtime/posixtime C/Python hybrid implementation for the POSIX timestamp manipulation would be beneficial. Largely, as Alexander points out, to make the distinction between the time module, the time.time function and datetime.time objects significantly clearer than it is now:
We can at least cut down the naming conflict to only exist between the latter two items. Such a transition could be made in the documentation (with a note in the "posixtime" documentation to say that it remains available as the time module for backwards compatibility reasons) as early as 3.2. Of course, any functionality gaps identified in datetime would still need to be closed. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Mon, 14 Jun 2010 20:09:02 -0400 Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Is it a common complaint, really? The common complaint, IMO, is that *none* of those two modules provides a complete feature set in itself.
I don't understand the purpose. I certainly like time.time() and I don't see the point of making it go away (will we have to use one of these "obvious" datetime-based one-liners instead?). Regards Antoine.

Le 15/06/2010 12:16, Antoine Pitrou a écrit :
The fact that we need dateutil or pytz to do some calculations is not optimal but it’s another concern. I agree that the overlap between time, datetime and calendar is annoying. More specifically, the multitude of types is bad (integer timestamp, time tuple, datetime object). Some bad one-liners that use some datetimes methods with unpacked (*arg) time tuples coming from another datetime method scream “shenanigans” to me.
time.time will still be available, just under another name that makes it clear it’s a binding to a low-level C concept. A user vote: +1 on renaming, +1 on improving datetime. Regards
participants (10)
-
Alexander Belopolsky
-
Antoine Pitrou
-
Brett Cannon
-
Cameron Simpson
-
M.-A. Lemburg
-
Michael Foord
-
Nick Coghlan
-
Senthil Kumaran
-
Terry Reedy
-
Éric Araujo