On Sat, May 30, 2015 at 10:06 PM, BartC <b...@freeuk.com> wrote: > On 29/05/2015 23:49, Chris Angelico wrote: >> That's 64-bit integers, not arbitrary-precision, but that's something >> at least. You do still need to worry about what happens when your >> numbers get too big; in Python, you simply don't. So it's still not >> quite there in terms of functionality. > > > But then the vast majority of integer operations won't require arbitrary > precision. (Or maybe Python programmers routinely use big integers all over > the place simply because they can.)
It's true that it won't often be an issue, but it's a matter of never needing to worry about it. Have you ever had to tweak an algorithm to ensure that you never go past some arbitrary boundary? In Python, with pure integer arithmetic, you can guarantee that mathematical truths are going to be maintained. There might still be good reason for doing operations in one order rather than another, but it's to do with performance, not correctness; the simple and naive algorithm can be used to verify correctness of any smarter algorithm. That's an important feature. > Python seems to have sacrificed some performance. When I questioned why 3.x > was slower than 2.x, merging int and long int (as I understood it) was one > of the reasons put forward. Yes, but that's an API point. A future version of Python could re-separate them as an optimization, as long as script-level code can't tell the difference. That's how Pike works, for instance; its native "int" type handles both machine words and bignums, with no visible distinction except performance. The common case (small numbers) is optimized; but short of probing for timings, there's no way to notice the actual boundary between the two. [1] This kind of change could be done to a future Python without breaking any existing code, and without breaking the expectation that integer arithmetic can go to infinity. ChrisA [1] Well, Pike also has a constant Int.NATIVE_MAX, in case a program is curious. But you get the idea. -- https://mail.python.org/mailman/listinfo/python-list