[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

[Guido van Rossum]

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/)