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

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 
interactive prompt.

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.

Eric.