On 1/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> 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 _______________________________________________ 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
