[Python-3000] [Python-3000-checkins] r60376 - in python/branches/py3k: Lib/test/test_float.py Lib/test/test_long.py Objects/stringlib/formatter.h
Guido van Rossum
guido at python.org
Mon Jan 28 05:23:29 CET 2008
On Jan 27, 2008 8:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> eric.smith wrote:
> > Author: eric.smith
> > Date: Sun Jan 27 22:07:59 2008
> > New Revision: 60376
> > Modified:
> > python/branches/py3k/Lib/test/test_float.py
> > python/branches/py3k/Lib/test/test_long.py
> > python/branches/py3k/Objects/stringlib/formatter.h
> > Log:
> > Restrict format presentation types to those specified in the 'Standard Format Specifiers' section of PEP 3101.
> I think this checkin goes too far in removing support for the floating
> point formatting codes from integers. Guido objected to %d working on
> floats last year, but expected %f and friends to continue to work on
> integers . This makes sense when you consider that there is no data
> loss in displaying an integer as a floating point number, while there is
> a definite potential for data loss when going the other way.
> Perhaps the PEP needs a tweak (referencing Guido's email) to state
> explicitly that the builtin integers understand the floating point
> formatting codes, but the builtin and standard library floating point
> types don't understand the integer codes? That area of the PEP is
> slightly problematic anyway where it suggests that integers could handle
> the floating point codes by delegating to float() - that isn't quite
> true, since the maximum precision on floats is less than the maximum
> precision on integers.
Agreed with Nick -- in general, the idea is that ints should be
allowed whenever floats are expected -- just not the other way around!
Python 2.x broke this in one important place, division -- 2/3 and
2.0/3.0 had different meanings there. We are fixing this in 3.0.
Please maintain this rule for formatting!
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000