[Python-ideas] Fwd: int('0x3241fca1')

[Bruce Leban]

On Thu, Feb 6, 2014 at 2:24 AM, Ram Rachum <ram.rachum at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140206/09172ac3/attachment-0001.html>