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.

Author tim.peters
Recipients doerwalter, ezio.melotti, georg.brandl, pitrou, r.david.murray, tim.peters
Date 2009-11-20.11:57:49
SpamBayes Score 3.31967e-11
Marked as misclassified No
Message-id <>
Ezio, it was Guido's design decision, it was intentional, and it's been
documented from the start(*).  So you can disagree with it, but you
won't get anywhere claiming it's "a bug":  intentional, documented
behaviors are never "bugs".  At best you can make a case for that
they're design errors.

But that won't fly either.  It's no more inconsistent than that, e.g.,
most floating-point numbers in practice aren't usually displayed with an
exponent, but if an exponent is needed, one is added to the output:

>>> .25
>>> .25 * 10**100

Overly literal readings don't help your case either.  Yes, __str__ aims
at producing nice output, but it's pedantic to argue as if that is, or
should be, __str__'s /only/ goal.  Python's design just isn't that
simple-minded ;-)  If someone uses non-zero microseconds, presumably
they want to see them.

Utterly trivial mechanical parsing of str() output is a non-goal in Python.

Of course the failing test should be repaired, and that was a good
catch.  But the chance of changing the language to make the test work
as-is is approximately 0%.

(*) The datetime docs already say:

__str__( ) 

For a datetime instance d, str(d) is equivalent to d.isoformat(' '). 
Date User Action Args
2009-11-20 11:57:52tim.peterssetrecipients: + tim.peters, doerwalter, georg.brandl, pitrou, ezio.melotti, r.david.murray
2009-11-20 11:57:52tim.peterssetmessageid: <>
2009-11-20 11:57:51tim.peterslinkissue7342 messages
2009-11-20 11:57:50tim.peterscreate