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
True

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.

Notice that this is no bug: there is no guarantee that repr() can
eval(). For some types it does, for others, it doesn't.

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

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)

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.

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.

I have a feeling that a successful resolution of bpo-1820 will make things simpler for this one, since time.struct_time uses structseq.

Also see bpo-11698

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 bpo-1820 will also fix this.

Confirmed this still fails:

>>> eval(repr(time.gmtime()))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
TypeError: structseq() takes at most 2 keyword arguments (9 given)

A

Reprs often round-trip but it is not a requirement, and if it’s not explicitly documented by the object then changing it would not qualify as a bug. Given the age of this ticket, I would suggest closing it.