Eric Smith wrote:
Note that in
http://mail.python.org/pipermail/python-dev/2008-February/077062.html,
Guido advocates not adding the __bin__ machinery, which is what lead to
the simple implementation of bin() just calling PyNumber_ToBase and
relying on __index__.
I don't think __bin__ should be added to 2.6. I don't see the point in
adding a feature in 2.6 that's implemented so differently in 3.0. It's
just asking for porting hassles.
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.
The 3.0 approach means that non-float floating point types still can't
be displayed properly by bin()/oct()/hex(). The current 2.6 approach
means every such class has to implement its own equivalent of
PyNumber_ToBase. Both are lousy solutions to a relative non-problem
(IMO) that can easily be implemented using a separate display function
for those applications which happen to need it.
I'd prefer to see a proper PEP for this proposing a new slot that lets
any class return an (integer_part, fraction_part) tuple of integers, and
have PyNumber_ToBase take care of the actual string formatting.
Introducing such a gratuitous incompatibility between 2.6 and 3.0 at
this late stage of the process certainly seems highly undesirable to me.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
