[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]

[Adding back the list.]

On Tue, Jun 24, 2008 at 9:53 PM, Raymond Hettinger <python at rcn.com> wrote:
>> While I think it's fine to have some function that reveals the binary
>> representation of floats, I don't think that overlaying this on
>> hex/oct/bin is worth the problems it causes.
>
> What problems?  The patch is clean.

Problems like no two people on python-dev agreeing on how exactly the
feature should be implemented. Problems like whether this goes way
beyond the philosophical underpinnings of bin/oct/hex. Problems like
what to do about other types that might want to overload hex/oct/bin.
See Kevin Jacobs' response.

>> This API appears to be
>> purely for educational purposes; why not implement something in pure
>> Python using the struct module that reveals the lay-out of the
>> floating-point value?
>
> This is not the internal floating point layout.  It is the real value
> expressed in exponential form.  It is more than educational --  it is a
> platform independent representation (look at Terry's reference -- it is the
> usual way to precisely specify a float value and it does not depend on
> atof() or vice versa).

Possibly, but it is only readable by a Python expression parser. For
all practical purposes "%.17g" % x works just as well. And this
bypasses the question "why overload this functionality on bin/hex/oct
rather than adding e.g. a new function to math or a new method to
float."

>> (There are also several things wrong with the specific patch, apart
>> from its lack of docs; #1 is the introduction of an externaly visible
>> symbol that doesn't start with _Py.)
>
> Will change the global symbol to _Py.  I already added docs to the patch.
>  Did you see the one that was uploaded a few hours ago (float6.diff)?

I don't care about the details of the patch until we have agreement
about which form the feature should take. We don't have that agreement
yet. I mentioned the flaws in the patch to point out that it was
apparently a rush job.

> I re-opened the discussion at your behest. [...]

I'm very glad you're giving the discussion a second chance. Please
give it a few days at least. My expectation is that the outcome will
be not to overload bin/hex/oct but to add a custom function to math or
a custom method to float, whose output can be further massaged to
create the platform-independent representation you're after. (I doubt
that it's worth changing pickle or marshal though, they are doing fine
with their respective current approaches.)

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