Author terry.reedy
Recipients chris.jerdonek, ezio.melotti, georg.brandl, gregory.p.smith, mark.dickinson, python-dev, serhiy.storchaka, terry.reedy
Date 2012-12-29.01:44:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1356745479.65.0.491688158745.issue16772@psf.upfronthosting.co.za>
In-reply-to
Content
To me the doc strongly implies, but does not boldly and baldly say, that base should be an int.

"A base-n literal consists of the digits 0 to n-1, with a to z (or A to Z) having values 10 to 35. The default base is 10. The allowed values are 0 and 2-36. Base-2, -8, and -16 literals can be optionally prefixed with 0b/0B, 0o/0O, or 0x/0X, as with integer literals in code. Base 0 means to interpret exactly as a code literal, so that the actual base is 2, 8, 10, or 16, and so that int('010', 0) is not legal, while int('010') is, as well as int('010', 8)."

I think it should be revised to say "The allowed values are ints 0 and 2-36." (or 'integers' or 'index values'). If it had been that already, the current behavior would clearly be a bug and eligible to be fixed in 3.2/3. As it is, I will not argue with whatever others do.

(I strongly suspect there are other places in the docs where int args are similarly implied but not explicit, but int-ness *is* checked. If someone were to complain about 0.0 being rejected, I expect we would correct the doc, not the code.;-)
History
Date User Action Args
2012-12-29 01:44:39terry.reedysetrecipients: + terry.reedy, georg.brandl, gregory.p.smith, mark.dickinson, ezio.melotti, chris.jerdonek, python-dev, serhiy.storchaka
2012-12-29 01:44:39terry.reedysetmessageid: <1356745479.65.0.491688158745.issue16772@psf.upfronthosting.co.za>
2012-12-29 01:44:39terry.reedylinkissue16772 messages
2012-12-29 01:44:38terry.reedycreate