This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, webograph
Date 2008-11-14.17:43:42
SpamBayes Score 1.4818147e-12
Marked as misclassified No
Message-id <1226684627.22.0.838216876725.issue2706@psf.upfronthosting.co.za>
In-reply-to
Content
I attaching webograph's patch updated to revision 67223 where I added a 
few tests.

I am +1 on the floor divide changes (allowing timedelta // timedelta), 
but I am not sure how true division should work if at all.  For the sake 
of argument, let's assume from __future__ import division or py3k.  
Currently: 

>>> timedelta(1)/2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 
'int'
>>> timedelta(1)/timedelta(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 
'datetime.timedelta'

With this patch, timedelta(1)/2 is still unsupported, but

>>> timedelta(1)/timedelta(2)
0.5

Note that this is probably correct behavior because timedelta/int true 
division does not make much sense, but there is a proposal (see issue1083) to make timedelta/int equivalent to timedelta//int.  (I am 
against issue1083 proposal and for webograph's approach, but this needs 
to be further discussed.)

Also, I've added a test that demonstrates the following behavior:

>>> int(timedelta.min/(timedelta.min//3))
2

This is not a bug in webograph's patch, but rather a bug in long true 
division, but it shows that true division may not be as useful as it 
seems.
History
Date User Action Args
2008-11-14 17:43:47belopolskysetrecipients: + belopolsky, webograph
2008-11-14 17:43:47belopolskysetmessageid: <1226684627.22.0.838216876725.issue2706@psf.upfronthosting.co.za>
2008-11-14 17:43:44belopolskylinkissue2706 messages
2008-11-14 17:43:43belopolskycreate