[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
ncoghlan at gmail.com
Tue Jun 24 15:17:50 CEST 2008
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
More information about the Python-Dev
mailing list