On Thu, Jun 26, 2008 at 5:50 AM, Raymond Hettinger <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
