On 1/16/06, Guido van Rossum
On 1/16/06, Alex Martelli
wrote: Is it finally time in Python 2.5 to allow the "obvious" use of, say, str(5,2) to give '101', just the converse of the way int('101',1) [I'm sure you meant int('101', 2) here]
Yep.
gives 5? I'm not sure why str has never allowed this obvious use -- any bright beginner assumes it's there and it's awkward to explain why it's not!-). I'll be happy to propose a patch if the BDFL blesses this, but I don't even think it's worth a PEP... it's an inexplicable though long-standing omission (given the argumentative nature of this crowd I know I'll get pushback, but I still hope the BDFL can Pronounce about it anyway;-).
I wish you had an argument better than "every bright beginner assumes it exists". :-)
What about "it should obviously be there"?-)
But (unlike for some other things that bright beginners might assume) I don't think there's a deep reason why this couldn't exist.
The only reasons I can come up with is "because input and output are notoriously asymmetric in Python" and "because nobody submitted a patch". :-)
OK, so, should I just submit a patch?
There are some corner cases to consider though.
- Should repr() support the same convention? I think not. - Should str(3.1, n) be allowed? I think not. - Should str(x, n) call x.__str__(n)? Neither. - Should bases other than 2..36 be considered? I don't think so.
Agreed on all scores.
Unfortunately this doesn't obsolete oct() and hex() -- oct(10) returns '012', while str(10, 8) soulc return '12'; hex(10) returns '0xa' while str(10, 16) would return 'a'.
Sure. hex(x) is like '0x'+str(x,16) and oct(x) is like '0'+str(x,8) but hex and oct are minutely more concise.
I do think that before we add this end-user nicety, it's more important to implement __index__() in Python 2.5. This behaves like
More important, sure, but also proportionally more work, so I don't see the two issues as "competing" against each other.
__int__() for integral types, but is not defined for float or Decimal. Operations that intrinsically require an integral argument, like indexing and slicing, should call __index__() on their argument rather than __int__(), so as to support non-built-in integral arguments while still complaining about float arguments.
Hear, hear. Multiplication of sequences, too.
This is currently implemented by explicitly checking for float in a few places, which I find repulsing. __index__() won't be requested by bright beginners, but it
You might be surprised by just how bright some (Python) beginners with deep maths background can be, though they might prefer to spell it differently (__int_and_i_really_mean_it__ for example'-) because it may not be obvious (if they're not Dutch) that multiplying a sequence has to do with 'indexing';-).
is important e.g. to the Numeric Python folks, who like to implement their own integral types but are suffering from that their integers aren't usable everywhere.
As the author and maintainer of gmpy I entirely agree -- I never liked the fact that instances of gmpy.mpq are "second class citizens" and i need to plaster int(...) around them to use them as list indices or to multiply sequences (I vaguely mentioned having in mind a 'baseinteger' check, but a special method returning the integer value, such as the __index__ you're talking about, is obviously better). Alex