Creating a reliable sandboxed Python environment

[Chris Angelico]

On Sat, May 30, 2015 at 10:06 PM, BartC <bc at 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.