This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: repr of time.struct_time type does not eval
Type: enhancement Stage: needs patch
Components: Extension Modules, Tests Versions: Python 3.7
Status: open Resolution:
Dependencies: 1820 8413 Superseder:
Assigned To: Nosy List: Arfrever, belopolsky, eric.araujo, georg.brandl, jwm, lilydjwg, loewis, r.david.murray, rhettinger, santoso.wijaya
Priority: normal Keywords:

Created on 2009-05-02 16:30 by jwm, last changed 2022-04-11 14:56 by admin.

Messages (9)
msg86958 - (view) Author: John Morton (jwm) Date: 2009-05-02 16:30
The output of repr on an object of type time.struct_time has changed
from 2.5 to 2.6, and can no longer be read in with an eval.

2.5 behaviour:

Python 2.5.4 (r254:67916, Apr  4 2009, 17:55:16) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> t1 = time.gmtime()
>>> t1_repr = repr(t1)
>>> t1_repr
'(2009, 5, 2, 16, 16, 43, 5, 122, 0)'
>>> t2 = eval(t1_repr)
>>> t1 == t2

Meanwhile in 2.6:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> t1 = time.gmtime()
>>> t1_repr = repr(t1)
>>> t1_repr
'time.struct_time(tm_year=2009, tm_mon=5, tm_mday=2, tm_hour=16,
tm_min=20, tm_sec=54, tm_wday=5, tm_yday=122, tm_isdst=0)'
>>> t2 = eval(t1_repr)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
TypeError: structseq() takes at most 2 arguments (9 given)

Obviously returning a time.time_struct based representation is the right
thing to do, but the repr of this flavour should eval.
msg86963 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-02 18:24
Notice that this is no bug: there is no guarantee that repr() can
eval(). For some types it does, for others, it doesn't.
msg86979 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-05-02 20:22
Also, the 2.5 behavior was not up to spec either: after eval() you get a
simple tuple, while the object before was a time.struct_time object.

(True, you can pass these tuples to the time functions, but an
eval()able repr() should reproduce the object exactly.)
msg87042 - (view) Author: John Morton (jwm) Date: 2009-05-03 11:44
While it's true that repr() methods cannot generally be expected to eval
back into an object of the same type, the old repr behaviour of the
struct_time object did effectively do so. Admittedly it was a kludge due
to the time module functions originally producing a tuple before the
advent of the struct_time type, but code that expected repr->eval
behaviour worked up to 2.5. It's also evident that who ever changed the
behaviour of time.struct_time.__repr__ intended that to sill be the
case, otherwise it would have produced a string of the form <time_struct

So I would describe this as a bug, otherwise you'd have to call it an
undocumented behaviour change :-)

The question remains, how to fix it? Should the repr output change to
time.struct_time((tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec,
tm_wday, tm_yday, tm_isdst)) or implement the keyword argument form?

(Note: python3.0 shares this new behaviour)
msg87053 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-03 17:31
> The question remains, how to fix it? 

Or whether to change it at all. It's hard to imagine that
applications may rely on that aspect of the behavior - they
have to use eval, after all.
msg133333 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-04-08 18:36
> Or whether to change it at all. It's hard to imagine that
> applications may rely on that aspect of the behavior - they
> have to use eval, after all.

I would like to see this fixed.  When working in interactive session, I find myself adding [:] to struct_time objects because otherwise I cannot copy the result and paste it back to CLI session.

Actually, the bigger problem for me is that struct_time repr is too verbose with repeated tm_ prefixes distracting from the data I want to see.  Chances are I will continue adding [:] or [:6] when I inspect struct_time values even if this issue gets fixed.

Overall I am +0 on fixing this.
msg133336 - (view) Author: Santoso Wijaya (santoso.wijaya) * Date: 2011-04-08 19:51
I have a feeling that a successful resolution of issue 1820 will make things simpler for this one, since time.struct_time uses structseq.
msg133356 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2011-04-08 23:25
Also see issue11698
msg197168 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-09-07 15:34
It is very surprising that evaling the repr doesn't work, since struct_time is documented to have a named tuple interface, and evaling the repr for a namedtuple works.  So hopefully fixing issue 1820 will also fix this.
Date User Action Args
2022-04-11 14:56:48adminsetgithub: 50157
2016-10-03 16:20:14belopolskysetpriority: low -> normal
versions: + Python 3.7, - Python 3.3
2015-01-21 08:15:01lilydjwgsetnosy: + lilydjwg
2013-10-10 04:55:00rhettingersetassignee: rhettinger ->
2013-09-25 14:21:32Arfreversetnosy: + Arfrever
2013-09-07 15:34:27r.david.murraysetnosy: + r.david.murray
messages: + msg197168
2011-07-13 15:40:23eric.araujosetnosy: + eric.araujo
2011-04-08 23:25:17rhettingersetassignee: rhettinger

messages: + msg133356
nosy: + rhettinger
2011-04-08 23:02:42amaury.forgeotdarcsetdependencies: + Enhance Object/structseq.c to match namedtuple and tuple api
2011-04-08 19:51:20santoso.wijayasetnosy: + santoso.wijaya
messages: + msg133336
2011-04-08 18:36:31belopolskysetpriority: normal -> low
versions: + Python 3.3, - Python 3.2
messages: + msg133333

assignee: belopolsky -> (no value)
stage: needs patch
2010-07-07 19:25:27belopolskysetdependencies: + String interpolation doesn't work with sys.version_info
2010-06-12 06:04:47belopolskysetassignee: belopolsky

nosy: + belopolsky
versions: + Python 3.2, - Python 2.6, Python 3.0
2009-05-03 17:31:02loewissetmessages: + msg87053
2009-05-03 11:44:09jwmsetmessages: + msg87042
versions: + Python 3.0
2009-05-02 20:22:02georg.brandlsetnosy: + georg.brandl
messages: + msg86979
2009-05-02 18:24:10loewissettype: behavior -> enhancement

messages: + msg86963
nosy: + loewis
2009-05-02 16:30:42jwmcreate