YADTR (Yet Another DateTime Rant)

[Ben Finney]

Roy Smith <roy at panix.com> writes:

> In article <5334b747$0$29994$c3e8da3$5496439d at news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>
> > On Thu, 27 Mar 2014 08:52:24 -0400, Roy Smith wrote:
> > > Give ma a real-life situation where you would want such behavior
> > > [the ‘datetime.timedelta.__str__’ method returning a string
> > > showing some portions negative and others positive].
> > 
> > Easy -- I'm debugging timedelta routines, and I want to easily see
> > that the timedeltas calculated match what I expect them to be when I
> > print them. The quickest, easiest and simplest way is for
> > str(timedelta) to follow the internal representation.
>
> That's what __repr__() is for.

Indeed, that is why Python's data model defines separate ‘__str__’ and
‘__repr__’ methods.

    object.__repr__(self)

    […] If at all possible, this should look like a valid Python
    expression that could be used to recreate an object with the same
    value (given an appropriate environment). If this is not possible, a
    string of the form <...some useful description...> should be
    returned.

    <URL:http://docs.python.org/3/reference/datamodel.html#object.__repr__>

    object.__str__(self)

    […] compute the “informal” or nicely printable string representation
    of an object. […] a more convenient or concise representation can be
    used.

    <URL:http://docs.python.org/3/reference/datamodel.html#object.__str__>

If you're a programmer wanting to know about the internal representation
of an object, call its ‘__repr__’ method (by calling ‘repr(foo)’).

If you're wanting to see a string representation that follows the
*semantics* of the object, call its ‘__str__’ method (by calling
‘str(foo)’).

If the ‘__str__’ method follows the internal representation at the
expense of the user's conceptual model, that's terrible (which I think
is what Roy means by “braindead”).

I wouldn't go as far as that insult, because it could be mere omission:

    The default implementation [of ‘__str__’] defined by the built-in
    type object calls object.__repr__().

So, where ‘str(foo)’ is returning an unhelpful representation that
follows the implementation, it could simply be that there is no
‘__str__’ defined for that type.

> > Oh look, that's exactly what the docs say:
> > 
> > "String representations of timedelta objects are normalized
> > similarly to their internal representation. This leads to somewhat
> > unusual results for negative timedeltas."
>
> Yes, I know that's what the docs say.  That's why it's not an 
> implementation bug.  It's a design bug :-)

One which to some extent violates the defined data model for Python
objects, and hence should be fixed.

-- 
 \      “I don't know half of you half as well as I should like, and I |
  `\   like less than half of you half as well as you deserve.” —Bilbo |
_o__)                                                          Baggins |
Ben Finney