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

On Tue, Dec 22, 2015 at 7:39 PM, Victor Stinner wrote: > Le lundi 21 décembre 2015, Guido van Rossum a écrit : >> >> I still think the repr change to use keywords has a good chance for 3.6. > > repr() with keywords is called a method, no? Like

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

repr() with keywords is called a method, no? Like isoformat() Victor Le lundi 21 décembre 2015, Guido van Rossum a écrit : > I still think the repr change to use keywords has a good chance for 3.6. > > --Guido (mobile) > On Dec 21, 2015 2:09 PM, "Chris Barker"

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

Would you be able to submit a patch to address the docstring issues? --Guido (mobile) On Dec 21, 2015 2:09 PM, "Chris Barker" wrote: > On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > >> >> Would there be value in changing the repr to use

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

I still think the repr change to use keywords has a good chance for 3.6. --Guido (mobile) On Dec 21, 2015 2:09 PM, "Chris Barker" wrote: > On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > >> >> Would there be value in changing the repr to use

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

On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > > Would there be value in changing the repr to use keyword arguments? > this thread got long, but it sounds like that won't be worth the backwards compatibility... > Worse, help(datetime.timedelta) in 3.6 doesn't

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

On Dec 21, 2015, at 14:07, Chris Barker wrote: > > and there are a LOT of next-to worthless docstrings in the stdlib -- it would > be nice to clean them all up. > > Is there any reason not to, other than someone having to do the work? Is this just a matter of

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

>> and there are a LOT of next-to worthless docstrings in the stdlib -- it >> would be nice to clean them all up. >> >> Is there any reason not to, other than someone having to do the work? And yes, I'd be willing to submit a patch. > Is this just a matter of _datetimemodule.c (and various

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

Guido van Rossum writes: > I'm sure that one often catches people by surprise. However, I don't > think we can fix that one without also fixing the values of the > attributes -- in that example days is -1 and seconds is 86340 (which > will *also* catch people by surprise). And

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

We're now thoroughly in python-ideas land. On Mon, Dec 21, 2015 at 7:39 AM, Random832 wrote: > Guido van Rossum writes: > > I'm sure that one often catches people by surprise. However, I don't > > think we can fix that one without also fixing the

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

From: gu...@python.org Date: Sun, 20 Dec 2015 14:33:46 -0800 To: ros...@gmail.com Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server) CC: python-dev@python.org > I'm just curious on the backward compatibility impact.

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

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: gu...@python.org Date: Sun, 20 Dec 2015 15:15:25 -0800 Subject: Re: [Python-Dev] Change the repr for

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

[Alexander Belopolsky] >> ... >> but I would really like to see a change in the repr of negative >> timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >> -1 day, 23:59:00 >> >> The above does not

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

On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum wrote: > but I would really like to see a change in the repr of negative timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >>

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

On Sun, Dec 20, 2015 at 5:00 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: > >> > A helpful trivia: a year is approximately π times 10 million seconds. >> >> Sadly doesn't help here, as the timedelta

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

[Tim] >> But I wouldn't change repr() - the internal representation is fully >> documented, and it's appropriate for repr() to reflect documented >> internals as directly as possible. [Alex] > Note that in the case of float repr, the consideration of user convenience > did win over "reflect

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

On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote: > On Mon, Dec 21, 2015 at 9:02 AM, Alexander Belopolsky > wrote: > > On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum > wrote: > >>> > >>> > >>> It's 11 days. Which is

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

On Sun, Dec 20, 2015 at 7:25 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum > wrote: > >> but I would really like to see a change in the repr of negative >>> timedeltas: >>> >>> >>> timedelta(minutes=-1)

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

On Sun, Dec 20, 2015 at 3:05 PM, Emanuel Barry wrote: > From: gu...@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

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

On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: > > A helpful trivia: a year is approximately π times 10 million seconds. > > Sadly doesn't help here, as the timedelta for a number of years looks like > this: > > >>> datetime.timedelta(days=365*11) >

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

On Sun, Dec 20, 2015 at 10:25 PM, Tim Peters wrote: > For > > >>> print(timedelta(minutes=-1)) > > I'd like to see: > > -00:01:00 > > But I wouldn't change repr() - the internal representation is fully > documented, and it's appropriate for repr() to reflect documented >

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

On Mon, Dec 21, 2015 at 12:00 PM, Alexander Belopolsky wrote: > On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: >> >> > A helpful trivia: a year is approximately π times 10 million seconds. >> >> Sadly doesn't help here, as the timedelta