[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 guido at python.org
Tue Jun 24 20:23:57 CEST 2008


On Tue, Jun 24, 2008 at 10:07 AM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Guido van Rossum wrote:
>>>
>>> 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.
>
> $ ./python
> Python 3.0b1+ (py3k:64491:64497M, Jun 24 2008, 07:14:03)
> [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> bin(1.0)
> '0b1 * 2.0 ** 0'
>>>>

Oops.

>>> 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"?)
>
> But apparently there's a desire to have bin(), oct(), and hex() support
> non-integer types.  See above, and issue 3008.  In 3.0, it's not possible to
> extend these to other types, because of the lack of __bin__, etc.  The test
> for float is hard coded in PyNumber_ToBase().

There are lots of desires. This particular one goes straight against
an earlier decision to simplify bin(), oct() and hex() by removing the
__oct__ and __hex__ special methods and not adding __bin__. Certainly
not something to be added without a PEP, certainly not after beta1 was
released already.

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


More information about the Python-Dev mailing list