[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

[Guido van Rossum]

On Tue, Jun 24, 2008 at 6:17 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

I missed the decision, but it's been added, at least to 2.6. However,
it was added after beta 1, so unless there was consensus about this,
IMO it should be rolled back.

> The 3.0 approach means that non-float floating point types still can't be
> displayed properly by bin()/oct()/hex().

Nor can float, AFAICT from the current 3.0 tree.

> The current 2.6 approach means
> every such class has to implement its own equivalent of PyNumber_ToBase.

But that's not supposed to be a burden -- any type purporting to
implement some kind of integer should implement __index__ anyway.
(Unless I misunderstand what you mean by "equivalent of"?)

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

I'd prefer not to see new features added at all, except for things
that were being planned before the beta and specifically got
permission to be added post-beta-1.

> Introducing such a gratuitous incompatibility between 2.6 and 3.0 at this
> late stage of the process certainly seems highly undesirable to me.

Same here.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)