[Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c

[Nick Coghlan]

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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org