RetroSearch Browse

Thu Jun 26 14:50:31 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-June/080670.html

> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-June/080670.html below:

[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