I was going to say the same as Amaury: timedelta / timedelta is
dimensionless (time units cancel each other in division) and the
advantage of this notation is that you get a way to express
timedelta.toxxx for all units accepted in constructor and even toweeks
becomes simple d / timedelta(7).

I've started flashing out a patch and then recalled that I've seen one
at issue2706 .  So instead of attaching a new patch here, I am going
to review the one in issue2706 now.

There was also some related discussion at issue4291 .   Apparently it
has been suggested that timedelta to integer and float conversions
would be a better alternative to timedelta / timedelta division.   I
disagree.  Integer conversion is ambiguous - should it be to seconds,
to microseconds or to timedelta.resolution (whatever that will become
in the future)?  Floating point conversion may loose precision as Tim
pointed out in msg26266 .  That would lead users to scratching their
heads over what to use float(d1)/float(d2) or float(d1)/int(d2) or
even int(d1)/int(d2) with true division on.

This said, let's move this discussion to issue2706 now.

On Fri, Nov 14, 2008 at 7:17 AM, Amaury Forgeot d'Arc
<report@bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa@gmail.com> added the comment:
>
>> timedelta / timedelta -> seconds? days? nanoseconds?
>
> The quotient of two timedelta is a dimensionless number with no unit:
>    timedelta(hours=1) / timedelta(minutes=5) == 12.0
> This seems well defined, where is the ambiguity?
>
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1673409>
> _______________________________________
>