Author terry.reedy
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.19:13:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1388949188.2.0.226652352273.issue19995@psf.upfronthosting.co.za>
In-reply-to
Content
Merely from reading the docs, including the hex() and {}.format sections, I consider the current
  '%x' % 1.5 == '1'
a bug in that I would expect either a Type or Value Error
or a hex fraction(!) ('1,8') matching the core of the output of float.hex(1.5). But given the history, I agree that a deprecation notice is needed first.

In 3.3 section 6.1.3.1. Format Specification Mini-Language, integer and float conversions are in separate tables, so no confusion is possible. In 3.3 section 4.7.2. printf-style String Formatting there is just one table with all conversion chars. I think the table would be clearer if it were somehow split into three sections: perhaps 3 otherwise blank rows containing  'integer', 'float', and 'other' in the Conversion column. (I don't know if this works for .rst tables.)

I think I would change the table for 3.4 with a note 8 that 'o', 'x', and 'X' currently accept floats by calling int() on the value, but that this implicit behavior is deprecated, so one should be explicit. The DeprecationWarning should also give the same remedy.
History
Date User Action Args
2014-01-05 19:13:08terry.reedysetrecipients: + terry.reedy, gvanrossum, rhettinger, mark.dickinson, pitrou, vstinner, larry, eric.smith, Arfrever, r.david.murray, skrah, ethan.furman, python-dev, serhiy.storchaka
2014-01-05 19:13:08terry.reedysetmessageid: <1388949188.2.0.226652352273.issue19995@psf.upfronthosting.co.za>
2014-01-05 19:13:08terry.reedylinkissue19995 messages
2014-01-05 19:13:07terry.reedycreate