[Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

[Raymond Hettinger]

From: "Guido van Rossum" <guido at python.org>
> Let's step back and discuss the API some more.
> 
> - Do we need all three?

I think so -- see the the reasons below.  Of course, my first 
choice was not on your list.  To me, the one obvious way to 
convert a number to a eval-able string in a different base is 
to use bin(), oct(), or hex().  But that appears to be off the 
table for reasons that I've read but don't make any sense to me.
It seems simple enough, extendable enough, and clean enough
for bin/oct/hex to use __index__ if present and __float__ if not.


> - If so, why not .tobase(N)? (Even if N is restricted to 2, 8 and 16.)

I don't think it's user-friendly to have the float-to-bin API
fail to parallel the int-to-bin API.  IMO, it should be done
the same way in both places.

I don't find it attractive in appearance.  Any use case I can
imagine involves multiple calls using the same base and I 
would likely end-up using functools.partial or somesuch
to factor-out the repeated use of the same variable.  In particular,
it's less usable with a series of numbers at the interactive prompt. 
That is one of the primary use cases since it allows you to see
exactly what is happening with float arithmetic:

>>> .6 + .7
1.2999999999999998
>>> bin(.6)
'0b10011001100110011001100110011001100110011001100110011 * 2.0 ** -53'
>>> bin(.7)
'0b1011001100110011001100110011001100110011001100110011 * 2.0 ** -52'
>>> bin(.6 + .7)
'0b101001100110011001100110011001100110011001100110011 * 2.0 ** -50'
>>> bin(1.3)
'0b10100110011001100110011001100110011001100110011001101 * 2.0 ** -52'

Or checking whether a number is exactly representable:

>>> bin(3.375)
'0b11011 * 2.0 ** -3'

Both of those bits of analysis become awkward with the tobase() method:

>>> (.6).tobase(2)
      ...



> - What should the output format be? I know you originally favored
> 0b10101.010101 etc. Now that it's not overloaded on the bin/oct/hex
> builtins, the constraint that it needs to be an eval() able expression
> may be dropped (unless you see a use case for that too).

The other guys convinced me that round tripping was important
and that there is a good use case for being able to read/write
precisely specified floats in a platform independent manner.
Also, my original idea didn't scale well without exponential
notation -- i.e.  bin(125E-100) would have a heckofa lot
of leading zeroes.   Terry and Mark also pointed-out that
the hex with exponential notation was the normal notation
used in papers on floating point arithmetic.  Lastly, once I
changed over to the new way, it dramatically simplified the
implementation.


Raymond