On Tue, Jun 24, 2008 at 10:07 AM, Eric Smith <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
