[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Sun, Sep 17, 2017 at 5:54 PM, Steve D'Aprano <steve+python at pearwood.info> wrote: > To even *know* that there are branches of maths where int/int isn't defined, you > need to have learned aspects of mathematics that aren't even taught in most > undergrad maths degrees. (I have a degree in maths, and if we ever covered > areas where int/int was undefined, it was only briefly, and I've long since > forgotten it.) How about this: >>> (1<<10000)/2 Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: integer division result too large for a float int/int is now undefined. In Py2, it perfectly correctly returns another integer (technically a long), but in Py3, it can't return a float, so it errors out. This is nothing to do with the mathematical notion of a "real", which is a superset of the mathematical notion of an "integer"; it's all to do with the Python notion of a "float", which is NOT a superset of the Python notion of an "integer". In Python 2, an ASCII string could be implicitly promoted to a Unicode string: >>> user_input = u"Real Soon Now?" >>> print("> " + user_input + " <") > Real Soon Now? < In Python 2 and 3, a small integer can be implicitly promoted to float: >>> user_input = 3.14159 >>> print(user_input + 1) 4.14159 Both conversions can cause data-dependent failures when used with arbitrary input, but are unlikely to cause problems when you're promoting literals. Both conversions require proximity to the other type. As long as you're explicit about the data type used for user input, you can short-hand your literals and get away with it: >>> # more likely, input came as text >>> user_input = float("1.234") >>> print(user_input + 1) 2.234 >>> # and hey, it works with other types too! >>> user_input = decimal.Decimal("1.234") >>> print(user_input + 1) 2.234 >>> user_input = fractions.Fraction("1.234") >>> print(user_input + 1) 1117/500 The trouble only comes when you take two pieces of user input in different types, and try to combine them: >>> user_1 = float("1.234") >>> user_2 = int("9"*999) # imagine someone typed it >>> user_1 + user_2 Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: int too large to convert to float Solution? Always use the right data types for user input. Easy enough. Python 3 introduces a completely different way to get failure, though. You can be 100% consistent with your data types, but then get data-dependent failures if, and only if, you divide. (Technically, not completely new in Py3; you can get this in Py2 with exponentiation - "2**-1" will yield a float. Far less likely to be hit, but could potentially cause the same problems.) I don't know of any exploits that involve this, but I can imagine that you could attack a Python script by forcing it to go floating-point, then either crashing it with a huge integer, or exploiting round-off, depending on whether the program is assuming floats or assuming ints. Python 3 *removed* one of these data-dependent distinctions, by making bytes+text into an error: >>> b"asdf" + u"qwer" u'asdfqwer' >>> b"asdf" + u"qwer" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't concat str to bytes But it added a different one, by allowing a common and normal operation to change a data type. Is it better to make things convenient for the case of small integers (the ones that are perfectly representable as floats), while potentially able to have problems on larger ones? Considering how large a "small integer" can be, most programmers won't think to test for overflow - just as many programmers won't test non-ASCII data. Thanks to Python 3, the "non-ASCII data" one isn't a problem, because you'll get the same exception with ASCII data as with any other; but the "small integer" one now is. Data-dependent type errors don't seem like a smart thing to me. ChrisA

- Prev by Date:
**Old Man Yells At Cloud** - Next by Date:
**Python built-ins versus Javascript [was Re: Old Man Yells At Cloud]** - Previous by thread:
**Old Man Yells At Cloud** - Next by thread:
**Old Man Yells At Cloud** - Index(es):