[Python-3000] PEP 3127 (integer literal syntax) -- any takers?

[Guido van Rossum]

On 6/11/07, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
> > On 6/10/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> Guido van Rossum wrote:
> >> > On 6/10/07, Georg Brandl <g.brandl at gmx.net> wrote:
> >> >> Guido van Rossum schrieb:
> >> >>> Very cool; thanks!!! No problems so far.
> >> >>>
> >> >>> I wonder if we need a bin() built-in that is to 0b like oct() is to 0o
> >> >>> and hex() to 0x?
> >> >> Would that also require a __bin__() special method?
> >> >
> >> > If the other two use it, we might as well model it that way.
> >>
> >> I must admit I've never understood why hex() and oct() don't just go
> >> through __int__() (Note that the integer formats are all defined as
> >> going through int() in PEP 3101).
> >>
> >> If we only want them to work for true integers, then we have __index__()
> >> available now.
> >
> > Well, maybe it's time to kill __oct__ and __hex__ then.
>
> Okay, attached is a patch to do that.
>
> It adds a new abstract function, PyNumber_ToBase, that converts an __index__able
> integer to an arbitrary base. bin(), oct() and hex() just uses it.
> (I've left the slots in the PyNumberMethods struct for now.)
>
> There was not much library code to change: only tests used the special methods.

Beautiful. Check it in please!

> Though /me wonders if we shouldn't just expose PyNumber_ToBase as a single
> function that mirrors int(str, base).

I think not. int(), oct(), hex() mirror the literal notations, and
because of this, they can insert the 0[box] prefix. I think the
discussions about this issue have revealed that there really isn't any
use case for other bases.

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