Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69089 > unrolled thread

YADTR (Yet Another DateTime Rant)

Back to article view | Back to comp.lang.python

Contents

  YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-25 20:58 -0400
    Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-25 18:19 -0700
    Re: YADTR (Yet Another DateTime Rant) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-26 09:27 +0000
    Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 08:37 -0500
      Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 08:04 -0700
        Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 10:39 -0500
          Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 17:58 +0200
            Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 11:34 -0500
              Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 19:13 +0200
              Re: YADTR (Yet Another DateTime Rant) Grant Edwards <invalid@invalid.invalid> - 2014-03-26 19:12 +0000
                Re: YADTR (Yet Another DateTime Rant) Ben Finney <ben+python@benfinney.id.au> - 2014-03-27 07:06 +1100
        Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 11:50 -0400
    Re: YADTR (Yet Another DateTime Rant) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-26 15:02 +0100
      Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 16:43 +0200
    Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 01:12 +1100
      Re: YADTR (Yet Another DateTime Rant) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-27 11:08 +1300
    Re: YADTR (Yet Another DateTime Rant) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-26 19:25 -0400
      Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 00:16 +0000
        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 12:28 +1100
          Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 21:38 -0400
            Re: YADTR (Yet Another DateTime Rant) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-27 08:40 +0000
        Re: YADTR (Yet Another DateTime Rant) Dan Sommers <dan@tombstonezero.net> - 2014-03-27 03:56 +0000
        Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 11:22 +0100
          Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 21:44 +1100
            Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 12:05 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 22:33 +1100
            Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 12:25 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 22:42 +1100
              Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-27 06:56 -0500
                Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-27 16:04 +0200
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 23:20 +1100
              Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-27 08:01 -0500
              Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 17:10 -0400
              Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-27 17:04 -0700
              Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 21:46 -0400
                Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 21:59 -0400
                  Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 22:24 -0400
                  Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:03 +1100
            Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 08:52 -0400
              Re: YADTR (Yet Another DateTime Rant) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-27 15:12 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-28 01:15 +1100
              Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 23:41 +0000
                Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 20:29 -0400
                  Re: YADTR (Yet Another DateTime Rant) Ben Finney <ben+python@benfinney.id.au> - 2014-03-28 11:43 +1100
                  Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 11:11 +0000
                    Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 08:30 -0400
                      Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-28 15:10 +0200
                        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 00:19 +1100
                          Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 09:22 -0400
                            Re: YADTR (Yet Another DateTime Rant) Rustom Mody <rustompmody@gmail.com> - 2014-03-28 06:30 -0700
                            Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 00:32 +1100
                        Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 09:20 -0400
                          Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-28 16:34 +0200
                      Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 14:35 +0000
                        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 02:25 +1100
    Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-26 16:33 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#69176

On 27/03/2014 01:38, Roy Smith wrote:
> In article <mailman.8597.1395883727.18130.python-list@python.org>,
>   Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Thu, Mar 27, 2014 at 11:16 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> If an event happened 30 hours ago, it is correct to say that it occurred
>>> "18 hours after 2 days ago", but who talks that way?
>>
>> That response demonstrates real genius. Rue the datetime? Who talks like that?
>
> "I had a dangling pointer error, and blew my stack to half past last
> wednesday"
>

IIRC the Germans (possibly amongst others) would say that as half to 
last thursday, or is that thurstag? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#69168

On Thu, 27 Mar 2014 00:16:57 +0000, Steven D'Aprano wrote:

> py> divmod(-30, 24)
> (-2, 18)
> 
> If an event happened 30 hours ago, it is correct to say that it
> occurred "18 hours after 2 days ago", but who talks that way?

Well, not *exactly*, but:

If today happens to be Wednesday, and an event occurred last Friday, I
might say "a week ago Friday."  Similarly, today, I could also say
"it'll be two years at my new job next month."

For an event that occurred approximately 310 days ago, I might say "less
than a year ago," and for an event that occurred approximately 350 days
ago, I might say "a little less than a year ago."

Or did you forget to put the winky there, and I fell for it?

11 years, 2 months, 26 days, 9 hours, 3 minutes, 27.4 seconds'ly yours,
Dan

[toc] | [prev] | [next] | [standalone]

#69180

On 27.03.2014 01:16, Steven D'Aprano wrote:

> py> divmod(30, 24)
> (1, 6)
> 
> That makes perfect intuitive sense: 30 hours is 1 day with 6 hours 
> remaining. In human-speak, we'll say that regardless of whether the 
> timedelta is positive or negative: we'll say "1 day and 6 hours from now" 
> or "1 day and 6 hours ago". But when we specify the sign:
> 
> py> divmod(-30, 24)
> (-2, 18)
> 
> If an event happened 30 hours ago, it is correct to say that it occurred 
> "18 hours after 2 days ago", but who talks that way?

Well, no matter how timedeltas internal representation is and if they
use modular division or (they probably do, I agree) this shouldn't
affect the display at all. Internally they can use any arbitrary
representation, but for the external representation I think a very sane
requirement should be that for a given timedelta t with t > 0 it is its
string representation str(t) would satisfy:

"-" + str(t) == str(-t)

Besides, there's an infinite amount of (braindead) timedelta string
representations. For your -30 hours, it is perfectly legal to say

123 days, -2982 hours

Yet Python doesn't (but chooses an equally braindead representation).

Where can I enter a PIP that proposes that all timedelta strings are
fixed at 123 days (for positive, non-prime amount of seconds) and fixed
at -234 days (for all negative or positive prime amount of seconds)?

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#69181

On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> Besides, there's an infinite amount of (braindead) timedelta string
> representations. For your -30 hours, it is perfectly legal to say
>
> 123 days, -2982 hours
>
> Yet Python doesn't (but chooses an equally braindead representation).

It's not "equally braindead", it follows a simple and logical rule:
Only the day portion is negative. That might not be perfectly suited
to all situations, but it does mean that adding and subtracting whole
days will never change the representation of the time. That's a
reasonable promise. What you propose is completely arbitrary, and yes
it WOULD be braindead to have str() return that (although of course
this should be accepted as input).

> Where can I enter a PIP that proposes that all timedelta strings are
> fixed at 123 days (for positive, non-prime amount of seconds) and fixed
> at -234 days (for all negative or positive prime amount of seconds)?
>

Doesn't need a PEP. Just subclass it or monkey-patch it and use it as
you will. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#69182

On 27.03.2014 11:44, Chris Angelico wrote:
> On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>> Besides, there's an infinite amount of (braindead) timedelta string
>> representations. For your -30 hours, it is perfectly legal to say
>>
>> 123 days, -2982 hours
>>
>> Yet Python doesn't (but chooses an equally braindead representation).
> 
> It's not "equally braindead", it follows a simple and logical rule:
> Only the day portion is negative. That might not be perfectly suited
> to all situations, but it does mean that adding and subtracting whole
> days will never change the representation of the time. That's a
> reasonable promise.

Why would the stability of the *string* output of the time
representation be of any interest whatsoever? Do you have any even
halfways reasonable usecase for that?

> What you propose is completely arbitrary, 

No. What I propose is that for t > 0 this holds:

"-" + str(t) == str(-t)

Which is far from arbitrary. It follows "natural" rules of inverting
something (-abs(x) == -x), and it yields a (truly) human-readable form
of showing a timedelta.

Please don't mix this up with the very apparent braindead proposal of
mine. In case you didn't notice, this was irony at work. The word
"braindead" I chose to describe the format should have tipped you off to
that.

>> Where can I enter a PIP that proposes that all timedelta strings are
>> fixed at 123 days (for positive, non-prime amount of seconds) and fixed
>> at -234 days (for all negative or positive prime amount of seconds)?
> 
> Doesn't need a PEP. Just subclass it or monkey-patch it and use it as
> you will. :)

Nonono, you misunderstand: I want everyone to suffer under the braindead
representation, just as it is now!

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#69184

On Thu, Mar 27, 2014 at 10:05 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> On 27.03.2014 11:44, Chris Angelico wrote:
>> On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>>> Besides, there's an infinite amount of (braindead) timedelta string
>>> representations. For your -30 hours, it is perfectly legal to say
>>>
>>> 123 days, -2982 hours
>>>
>>> Yet Python doesn't (but chooses an equally braindead representation).
>>
>> It's not "equally braindead", it follows a simple and logical rule:
>> Only the day portion is negative. That might not be perfectly suited
>> to all situations, but it does mean that adding and subtracting whole
>> days will never change the representation of the time. That's a
>> reasonable promise.
>
> Why would the stability of the *string* output of the time
> representation be of any interest whatsoever? Do you have any even
> halfways reasonable usecase for that?
>
>> What you propose is completely arbitrary,
>
> No. What I propose is that for t > 0 this holds:
>
> "-" + str(t) == str(-t)
>
> Which is far from arbitrary.

When you said "equally braindead", I took that as indicating that the
current representation is as braindead as "123 days, -2982 hours". My
point is that it's not as arbitrary as that. Your "real proposal", if
you like, is arguably better; but I'm just saying that the current one
isn't arbitrary.

> It follows "natural" rules of inverting
> something (-abs(x) == -x), and it yields a (truly) human-readable form
> of showing a timedelta.
>
> Please don't mix this up with the very apparent braindead proposal of
> mine. In case you didn't notice, this was irony at work. The word
> "braindead" I chose to describe the format should have tipped you off to
> that.

Yes, I knew that that was irony. I was taking argument with your
declaration that the current form is just as bad. Taking it to a
different type: The repr() of a string tries to be short, where
possible, by using either single or double quotes, but won't use a raw
representation, nor triple-quoted:

>>> ' \' '
" ' "
>>> " \" "
' " '
>>> ' \"\'\"\'\"\'\"\' '
' "\'"\'"\'"\' '
>>> " \"\'\"\'\"\'\"\' "
' "\'"\'"\'"\' '
>>> ''' "'"'"'"' '''
' "\'"\'"\'"\' '
>>> r' \\\\\\\\\\\\\\ '
' \\\\\\\\\\\\\\\\\\\\\\\\\\\\ '

You could argue that representing a string as raw or triple-quoted
would be "more correct", and yet the current repr is not arbitrary.
The current form is not actively bad, even if it would be possible to
find something better.

>>> Where can I enter a PIP that proposes that all timedelta strings are
>>> fixed at 123 days (for positive, non-prime amount of seconds) and fixed
>>> at -234 days (for all negative or positive prime amount of seconds)?
>>
>> Doesn't need a PEP. Just subclass it or monkey-patch it and use it as
>> you will. :)
>
> Nonono, you misunderstand: I want everyone to suffer under the braindead
> representation, just as it is now!

Oh, absolutely! In that case, just slip a patch into the next point
release; people won't mind that changing in 3.4.1!

ChrisA

[toc] | [prev] | [next] | [standalone]

#69183

On 27.03.2014 11:44, Chris Angelico wrote:

> It's not "equally braindead", it follows a simple and logical rule:
> Only the day portion is negative.

The more I think about it, the sillier this rule seems to me.

A timedelta is a *whole* object. Either the whole delta is negative or
it is not. It doesn't make sense to split it up in two parts and
arbitrarily define one to be always nonnegative and the other to have no
restrictions.

The only locical reasoning behind this could be to argue that "-2 days"
makes more sense than "-15 minutes". Which it doesn't.

Worse: Negating a timedelta (which I would argue is a fairly common
operation) makes the whole thing unstable representation-wise:

>>> str(datetime.timedelta(2, 30))
'2 days, 0:00:30'
>>> str(-datetime.timedelta(2, 30))
'-3 days, 23:59:30'

And it makes it extremely error-prone to the reader:

>>> str(datetime.timedelta(0, -1))
'-1 day, 23:59:59'

This looks MUCH more like "almost two days ago" than

'-00:00:01'

does.

In any case, the str() function is *only* about the representation that
can be read by humans. Therefore its highest priority should be to
output something that can, in fact, be easily parsed by humans. The
current format is nothing of the sort.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#69185

On Thu, Mar 27, 2014 at 10:25 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> And it makes it extremely error-prone to the reader:
>
>>>> str(datetime.timedelta(0, -1))
> '-1 day, 23:59:59'
>
> This looks MUCH more like "almost two days ago" than
>
> '-00:00:01'
>
> does.

It's easy when the timedelta is >-1 day. Is it as clear when it's
further negative?

In any case... what I'd suggest would be opening a tracker issue, or
discussing this on python-ideas, and seeing what core devs think of
the matter. I think that, on balance, it's probably better to show the
whole thing with the same sign; but should it be:

>>> str(datetime.timedelta(-1, -1))
'-1 day, 00:00:01'

or should the hyphen be repeated:

>>> str(datetime.timedelta(-1, -1))
'-1 day, -00:00:01'

? How does it read in a larger expression? All this bikeshedding, and
more, available gratis on python-ideas. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#69186

I took a moment to scan the datetime documentation. The behavior of
str() on timedelta objects is very consistent, and matches the
internal representation. From the docs:

str(t) Returns a string in the form [D day[s], ][H]H:MM:SS[.UUUUUU],
where D is negative for negative t. (5)

Note (5) reads: String representations of timedelta objects are
normalized similarly to their internal representation. This leads to
somewhat unusual results for negative timedeltas.

Feel free to submit a patch to improve str(t), where t is negative,
though as Chris suggested, hashing this out on python-ideas would be a
good idea. I suggest you start with some concrete examples. There are,
as I see it, two common cases where t is negative:

  -1 day < t < 0

and

  t <= -1 day

Skip

[toc] | [prev] | [next] | [standalone]

#69191

Skip Montanaro <skip@pobox.com>:

> Feel free to submit a patch to improve str(t), where t is negative,

The cat's out of the bag already, isn't it?


Marko

[toc] | [prev] | [next] | [standalone]

#69187

On Thu, Mar 27, 2014 at 10:56 PM, Skip Montanaro <skip@pobox.com> wrote:
> There are,
> as I see it, two common cases where t is negative:
>
>   -1 day < t < 0
>
> and
>
>   t <= -1 day

There are two types of negative numbers: Those closer to zero than -1,
and those not closer to zero than -1. Yeah, I think those are the most
common cases. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#69189

>> There are,
>> as I see it, two common cases where t is negative:
>>
>>   -1 day < t < 0
>>
>> and
>>
>>   t <= -1 day
>
> There are two types of negative numbers: Those closer to zero than -1,
> and those not closer to zero than -1. Yeah, I think those are the most
> common cases. :)

Sorry I wasn't clear. I see two cases w.r.t. *display*, those where
you need to display the number of days back (possibly accounting for
even larger time intervals to make it more human readable), those
where you don't.  Yes, as you observed, they completely cover the
negative timedelta space with two non-overlapping intervals.

Roy's original rant was about how a negative timedelta was
stringified, when what he seemed to care about was mostly the time
interval between now and the previous sunset (which will be less than
a day, unless your day length is advancing -- between the winter and
summer solstices -- and you compute that interval a few seconds before
sunset). The common "how long ago was sunset?" (|delta| < 1 day) case
is handled just fine by my little negate-the-timedelta hack, e.g.:

>>> "-%s" % (-datetime.timedelta(hours=-17, minutes=-12, seconds=-25.234))
'-17:12:25.234000'

Negative timedeltas with a magnitude of one day or more require
something else, perhaps like the ISO8601 duration stuff (which I
personally find distasteful, but that might be the best you can do in
the absence of an anchor datetime).

Skip

[toc] | [prev] | [next] | [standalone]

#69219

On 3/27/2014 7:42 AM, Chris Angelico wrote:

> In any case... what I'd suggest would be opening a tracker issue, or
> discussing this on python-ideas, and seeing what core devs think of
> the matter. I think that, on balance, it's probably better to show the
> whole thing with the same sign; but should it be:

Before doing so, I suggest looking for the design discussion either on 
the tracker or in python-ideas or py-dev lists.


>>>> str(datetime.timedelta(-1, -1))
> '-1 day, 00:00:01'
>
> or should the hyphen be repeated:
>
>>>> str(datetime.timedelta(-1, -1))
> '-1 day, -00:00:01'

'-(1 day, 00:00:01)' should be unambiguous.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#69228

On 03/27/2014 02:10 PM, Terry Reedy wrote:
> On 3/27/2014 7:42 AM, Chris Angelico wrote:
>
>> In any case... what I'd suggest would be opening a tracker issue, or
>> discussing this on python-ideas, and seeing what core devs think of
>> the matter. I think that, on balance, it's probably better to show the
>> whole thing with the same sign; but should it be:
>
> Before doing so, I suggest looking for the design discussion either on the tracker or in python-ideas or py-dev lists.
>
>>--> str(datetime.timedelta(-1, -1))
>> '-1 day, 00:00:01'
>>
>> or should the hyphen be repeated:
>>
>>--> str(datetime.timedelta(-1, -1))
>> '-1 day, -00:00:01'
>
> '-(1 day, 00:00:01)' should be unambiguous.

Or change the comma to an and:

'-1 day and 00:00:01'

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#69236

On 3/27/2014 5:10 PM, Terry Reedy wrote:
> On 3/27/2014 7:42 AM, Chris Angelico wrote:
>
>> In any case... what I'd suggest would be opening a tracker issue, or
>> discussing this on python-ideas, and seeing what core devs think of
>> the matter. I think that, on balance, it's probably better to show the
>> whole thing with the same sign; but should it be:
>
> Before doing so, I suggest looking for the design discussion either on
> the tracker or in python-ideas or py-dev lists.

And skip the troll word 'braindead'.

Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#69238

In article <mailman.8647.1395971209.18130.python-list@python.org>,
 Terry Reedy <tjreedy@udel.edu> wrote:

> On 3/27/2014 5:10 PM, Terry Reedy wrote:
> > On 3/27/2014 7:42 AM, Chris Angelico wrote:
> >
> >> In any case... what I'd suggest would be opening a tracker issue, or
> >> discussing this on python-ideas, and seeing what core devs think of
> >> the matter. I think that, on balance, it's probably better to show the
> >> whole thing with the same sign; but should it be:
> >
> > Before doing so, I suggest looking for the design discussion either on
> > the tracker or in python-ideas or py-dev lists.
> 
> And skip the troll word 'braindead'.
> 
> Terry Jan Reedy

I apologize for my poor choice of vocabulary.

[toc] | [prev] | [next] | [standalone]

#69240

On 3/27/2014 9:59 PM, Roy Smith wrote:
> In article <mailman.8647.1395971209.18130.python-list@python.org>,
>   Terry Reedy <tjreedy@udel.edu> wrote:
>
>> On 3/27/2014 5:10 PM, Terry Reedy wrote:
>>> On 3/27/2014 7:42 AM, Chris Angelico wrote:
>>>
>>>> In any case... what I'd suggest would be opening a tracker issue, or
>>>> discussing this on python-ideas, and seeing what core devs think of
>>>> the matter. I think that, on balance, it's probably better to show the
>>>> whole thing with the same sign; but should it be:
>>>
>>> Before doing so, I suggest looking for the design discussion either on
>>> the tracker or in python-ideas or py-dev lists.
>>
>> And skip the troll word 'braindead'.

> I apologize for my poor choice of vocabulary.

I actually meant if you post on the tracker or python-ideas. There is a 
little more leeway here. But as you maybe noticed. even here a trollish 
word can divert discussion from you main point.

Back to your main point: the current output looks strange to me also. 
But I did not follow the datetime development discussion. I do know that 
the people responsible are not normally braindead ;-).

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#69244

On Fri, Mar 28, 2014 at 1:24 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> I do know that the people responsible are not normally braindead ;-).

Yeah, anyone who develops Python is clearly abnormally braindead...

*dives for cover*

ChrisA

[toc] | [prev] | [next] | [standalone]

#69188

> On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> > Besides, there's an infinite amount of (braindead) timedelta string
> > representations. For your -30 hours, it is perfectly legal to say
> >
> > 123 days, -2982 hours
> >
> > Yet Python doesn't (but chooses an equally braindead representation).


In article <mailman.8613.1395917059.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:
> It's not "equally braindead", it follows a simple and logical rule:
> Only the day portion is negative.

Simple and logical, yes.  But also entirely braindead.

> That might not be perfectly suited to all situations

Give ma a real-life situation where you would want such behavior.

> What you propose is completely arbitrary, and yes
> it WOULD be braindead to have str() return that

Chris, I believe you need to have your sarcasm detection circuitry 
recalibrated :-)

[toc] | [prev] | [next] | [standalone]

#69192

On 27-03-14 13:52, Roy Smith wrote:
>> On Thu, Mar 27, 2014 at 9:22 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>>> Besides, there's an infinite amount of (braindead) timedelta string
>>> representations. For your -30 hours, it is perfectly legal to say
>>>
>>> 123 days, -2982 hours
>>>
>>> Yet Python doesn't (but chooses an equally braindead representation).
>
> In article <mailman.8613.1395917059.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>> It's not "equally braindead", it follows a simple and logical rule:
>> Only the day portion is negative.
> Simple and logical, yes.  But also entirely braindead.

That you don't have a use for it and don't like it doesn't
make it brain dead.
 

>> That might not be perfectly suited to all situations
> Give ma a real-life situation where you would want such behavior.

What good would that do? The fact that someone else could
give a real-life situation where they wanted that, wouldn't
mean that you would recognize it as a situation where you
wanted it, and so you could still call it brain dead.

I don't recall specifics, but I do remember multiple times
where I was working with a structure that consisted of
a whole part and a fracture part where I found it useful
to have the fracture part always positive and displayed
as such.

Your background is obviously different and you don't like it.
Fine, that doesn't make it brain dead.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web