Author ethan.furman
Recipients Arfrever, eric.smith, ethan.furman, gvanrossum, larry, mark.dickinson, pitrou, python-dev, r.david.murray, rhettinger, serhiy.storchaka, skrah, terry.reedy, vstinner
Date 2014-01-05.15:38:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1388936283.78.0.107419623278.issue19995@psf.upfronthosting.co.za>
In-reply-to
Content
I think the code-breakage issue is that although this is a bug now, it did not use to be a bug.  (Or maybe it was always a bug, but nobody noticed -- I don't know when hex() and oct() were introduced.)

Basically, having %o and %x work with floats was the intended behavior, as there were tests to make sure it worked.

But hex() and oct() were designed to only work with integer types, resulting in two ways to get an octal or hexadecimal string, one of which worked with non-ints, and one which didn't.

tarfile.py, for example, was using %o to convert a stat member (a timestamp?) from int/float to octal.

It is agreed that working with non-ints is no longer the intended behavior, but there is undoubtedly code that uses it -- especially in cases where the return value could be either an int or a float.
History
Date User Action Args
2014-01-05 15:38:03ethan.furmansetrecipients: + ethan.furman, gvanrossum, rhettinger, terry.reedy, mark.dickinson, pitrou, vstinner, larry, eric.smith, Arfrever, r.david.murray, skrah, python-dev, serhiy.storchaka
2014-01-05 15:38:03ethan.furmansetmessageid: <1388936283.78.0.107419623278.issue19995@psf.upfronthosting.co.za>
2014-01-05 15:38:03ethan.furmanlinkissue19995 messages
2014-01-05 15:38:03ethan.furmancreate