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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
