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.
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()).
Raymond
_______________________________________________
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
