➜

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.

作者 mark.dickinson
收信人 belopolsky, mark.dickinson, mcherm, rhettinger, stutzbach, tim.peters, vstinner
日期 2010-05-21.08:42:42
SpamBayes Score 4.2137588e-05
Marked as misclassified 否
Message-id <1274431365.66.0.363293147539.issue1289118@psf.upfronthosting.co.za>
In-reply-to
内容
Alexander, I still don't understand your objection.  What's the downside of allowing the multiplication or division of a timedelta by a float?

Perhaps it's true that there are applications where timedeltas are best viewed as integers (with an implicitt 'microsecond' unit), but I think it's also true that there are plenty of applications where they're just regarded as a representation of a physical quantity, and there this proposal seems entirely appropriate.

I *would* want the timedelta * float and timedelta / float operations to be correctly rounded, so that behaviour is entirely predictable;  the current patch doesn't do that.  But it wouldn't be hard to implement:  there are functions available to express a float as a quotient of two integers, and after that the computation can be performed in integer arithmetic.
历史
日期 用户 动作 参数
2010-05-21 08:42:46mark.dickinson修改recipients: + mark.dickinson, tim.peters, mcherm, rhettinger, belopolsky, vstinner, stutzbach
2010-05-21 08:42:45mark.dickinson修改messageid: <1274431365.66.0.363293147539.issue1289118@psf.upfronthosting.co.za>
2010-05-21 08:42:44mark.dickinson链接issue1289118 messages
2010-05-21 08:42:42mark.dickinson创建