bltinmodule.c (original) (raw)

Guido van Rossum guido at python.org
Thu Jun 26 16:08:24 CEST 2008

On Thu, Jun 26, 2008 at 5:50 AM, Raymond Hettinger <python at rcn.com> wrote:

Just as a contrary point, I'm not particularly keen on the output format (which takes the form '0b1 * 2.0 ** 0' as far as I can see), That format was requested by everyone else on the tracker discussion. What I originally wanted was something like 0b11.0101. But that didn't round-trip through eval, it didn't match the style used in the numerical papers referenced by Terry Reedy, and it didn't scale well with inputs like 1.1E+100.

and I'm definitely not keen on the fact that it's overloaded on the hex/bin/oct builtins.

Can't it be a separate function? Simplicity. bin/oct/hex have the job of giving alternate base representations for numbers. Nothing is gained by adding a duplicate set of functions in the math module for float inputs.

I disagree, and others here have disagreed too. We made a consicous decision to remove the overloading of hex/oct/bin via hex/oct/bin in 3.0, in order to simplify these functions, which only work for integers, not for any other style of numbers. If bin(3.4) works, why not bin() of a Fraction, or of a complex number? Or for that matter, why not hex() of a string? All these have some use case. But is that use case important enough to put it in the bin()/hex()/oct() built-in functions? Why not hex() of a dictionary? Where does it end? We drew a line in the sand -- these are only for ints.

would it not be better if it were machine-parseable, rather than executable? We already have struct.pack for machine-parseable output. This is supposed to be human readable as well as providing an exact, platform indepent way of specifying a particular float value (something that's useful in testing algorithms like that in math.sum()).

The only use cases you bring up appear to be in testing and education. This is not a strong enough motivation for adding a wart to the bin/oct/hex builtins. I'm sure you can write the same thing in pure Python -- wouldn't that be good enough for testing? And if you then put it somewhere in a module in the stdlib, wouldn't that be good enough for education?

There's a strong movement for keeping the language small and clean. Adding more overloaded functionality to built-in functions goes counter to that ideal. A new stdlib function causes no overhead to the language definition (and built-ins are part of the language).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list