datetime: .datetime-.datetime = .timedelta, .time-.time=TypeError ?

Christos TZOTZIOY Georgiou tzot at sil-tec.gr
Tue Sep 9 03:39:38 EDT 2003


On Mon, 8 Sep 2003 20:57:46 -0400, rumours say that "Tim Peters"
<tim.one at comcast.net> might have written:

>[Christos TZOTZIOY Georgiou]
>> Is there any reason for datetime.time subtraction not returning a
>> datetime.timedelta object, just like datetime.datetime subtraction
>> does?
>
>Guido didn't want time objects participating in arithmetic because the
>desired semantics are unclear.  For example, if you allow
>
>    time1 - time2
>
>to return a timedelta, then you'll also want to allow
>
>    time2 + timedelta
>
>to return a time, and then you've got to make up rules for what happens when
>adding spills over a midnight boundary.  Should it "wrap around"?  Raise
>OverflowError?  Guido didn't want to endure arguments about that.

So it's by design.

[snip of the above not applying to datetime objects]

>> It doesn't feel good having to use dumb year, month, day
>> arguments constructing datetime object when doing only time
>> arithmetic.
>
>What's wrong with using timedeltas?
>
>>>> print timedelta(hours=3, minutes=15) - timedelta(hours=2, minutes=45)
>0:30:00

A perfectly clear solution; it's just the RTFM-F [1] virus, I overlooked
the keyword arguments...

>> If there is no specific reason apart from lack of time (no pun), I'm
>> willing to research it and write a patch (I haven't seen the code,
>> but I believe it would be quite easy).
>
>Selling it would be harder than writing it.

Basically, I asked for some reasoning --which you provided in the first
paragraphs of your reply-- just in case the issue was overlooked; since
it wasn't (and I got a solution!), I'm OK and not at all anxious to sell
a patch :)

Thanks.

[1] final F standing for First
-- 
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.




More information about the Python-list mailing list