bltinmodule.c (original) (raw)

Raymond Hettinger python at rcn.com
Thu Jun 26 21:52:25 CEST 2008

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

More information about the Python-Dev mailing list