[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
eric+python-dev at trueblade.com
Thu Jun 26 16:59:34 CEST 2008
Eric Smith wrote:
> Actually, after saying I was opposed to __bin__ in 2.6, I said:
> "Instead, I think the approach used in 3.0 (r64451) should be used
> instead. That is, if this feature exist at all. I'm -0 on adding
> bin(), etc. to floats."
> My last sentence is a little unclear. I meant I'm -0 on adding floats
> as arguments to bin(), oct(), and hex(). Primarily because a) it's not
> extensible in 3.0, and b) I find it surprising, in that I'd expect those
> functions to throw an error for non-integral types (that is, those not
> having __index__). I think adding a "float_as_binary_expression()"
> (with a better name) in some module would get the functionality you
> seek. What is gained by adding this to bin() and friends?
And to clarify myself, yet again (from private email with Raymond):
I actually think it's a useful feature, just not in bin(). I'm sure it
will land somewhere, and I'm also sure I'll use it, at least from the
And if bin() were generally extensible for all types, I wouldn't really
even care all that much if this feature landed in bin(). But 3.0 is
going in the opposite direction, which is what much of my concern is
based on, and why I commented at the outset on the 2.6 approach
differing from the 3.0 approach.
More information about the Python-Dev