[Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

[Emanuel Barry]

Half-rhetorical half-genuine; you know better than me the history of breakage due to such changes, anyway. I can't really think of anything you haven't, so I'll just sit back.

From: guido at python.org
Date: Sun, 20 Dec 2015 15:15:25 -0800
Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)
To: vgr255 at live.ca
CC: rosuav at gmail.com; python-dev at python.org

On Sun, Dec 20, 2015 at 3:05 PM, Emanuel Barry <vgr255 at live.ca> wrote:



From: guido at python.org
> I'm just curious on the backward compatibility impact.

I'm just curious on the number of programs depending on the repr() of any object at all in production (not counting tests). I could be wrong, but it seems foolish to rely on that, especially since this is something that we *can* change on an (almost) arbitrary basis. IMO, the repr() is meant to aid the programmer - not specifying keyword arguments here does quite the opposite of that :)
Not sure if you meant that as a rhetorical question or sarcastically. While you're right that ideally changing the repr() of an object shouldn't affect production work, in practice it can break any number of things, for example over-specified unit tests or poor integrations that end up parsing the string (perhaps in a different language than Python).

We've encountered such issues many times in the past (for example, massive doctest breakage when we randomized the string hash) so we have to at least consider the possibility. In this case I expect there will be little effect, but it doesn't hurt asking around -- who knows what someone reading this remembers (besides asking pedantic questions :-).

-- 
--Guido van Rossum (python.org/~guido)
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151220/9fbb0b74/attachment.html>