On Thu, Feb 6, 2014 at 2:24 AM, Ram Rachum <ram.rachum@gmail.com> wrote:

What do you think about letting the `int` constructor automatically understand the number type without specifying base if given a prefix, so int('0x3414fa') would immediately work without specifying a base of 16?

What's the use case? Do you expect prefixes in user input? In data you're reading from files and parsing where you don't know the base? I don't see it.

This would change the behavior of current code and potentially introduce bugs. For example, this allows attackers to trick programs into accepting aliases of numbers they would not otherwise accept. Search [overlong utf-8 sequences] for an example of this kind of attack.

And it would be quite strange that a base of 10 means sometimes 10 and sometimes look at a prefix while all other bases mean exactly what they say.

>>> int('0xa', 16)

10
>>> int('0xa', 36)

1198
>>> int('1e1', 16)

481

EIBTI: If there's a compelling use case, a better idea IMHO would be to allow int(x, None) to mean to use prefixes or even a different function, like parse_int. I think e suffixes have long implied float values and I see little benefit in allowing them here.

ASIDE: int accepts a prefix when it matches the base you're parsing and rejects invalid prefixes. Most of the time.

>>> int('0x111', 16)
273
>>> int('0b111', 2)

7

>>> int('0x111', 2)

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

ValueError: invalid literal for int() with base 2: '0x111'

>>> int('0b111', 16)

45329

The last case might be surprising for a moment but hardly wrong, and it's a good illustration of the problem of trying to guess what things mean.

--- Bruce