[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 (original) (raw)

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

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 PyNumberToBase().

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