[issue2706] datetime: define division timedelta/timedelta

[Tennessee Leeuwenburg]

Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

Hi all,

I'm trying to help out by reviewing issues in the tracker... so this is 
just a first attempt and I hope it is somewhat useful. This issue covers 
a number of discrete functional changes. I here review each in turn:

1) Allow truediv, the operator '/', to be applied to two timedeltas 
(e.g. td1 / td2). The return value is a float representing the number of 
times that td2 goes into td1.

Evaluation: Since both time deltas are quantitative values of the same 
unit, it makes sense they should be able to support basic math 
operations. In this case, operation to be added is '/' or truediv. I 
would personally find this functionality useful, and believe it is a 
natural addition to the code.

Recommendation: That this functionality be recommended for development

2) Allow truediv to be applied to a timedelta and an int or float. The 
return value is a timedelta representing the fractional proportion of 
the original timedelta.

Evaluation: This makes total sense.
Recommendation: That this functionality be recommended for development

2) Allow divmod, the operator '%', to be applied to two timedeltas (e.g. 
td1 % td2). I think there is some debate here about whether the return 
value be an integer in microsends, or a timedelta. I personally believe 
that a timedelta should be returned, representing the amount of time 
remaining after (td1 // td2)  * td2 has been subtracted.

The alternative is an integer, but due to a lack of immediate clarity 
over what time quanta this integer represents, I would suggest returning 
a unit amount. There is also some discussion of returning (long, 
timedelta), but I personally fail to see the merits of returning the 
long without some unit attached.

3) Allow divmod, the operator '%', to be applied to a timedelta and an 
integer or float. (e.g. <timedelta> % 3). I'm not quite as sold on this.  
I suggest that more discussion is required to flesh this out further.


A patch has been attached which implements some of this behaviour. I 
would suggest that it's valuable to start doing this work in discrete 
chunks so that progress can be begun before the issues under debate are 
resolved. I suggest that it would be appropriate to create three smaller 
issues, each tackling just one piece of functionality. This should make 
the changes more atomic and the code patch simpler.

-T

----------
message_count: 19.0 -> 20.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________