Get rid of "small" ints?

[markshannon]

The "small" integers from -5 to 256 (or thereabouts) are cached to reduce excessive allocations.
However, having to handle these ints specially prevents:

• Specializing binary operations with refcount(left) == 1 to perform the operation inplace.
• Inlining of int creation into int operations
• Complication of specialized code for range, enumerate, etc. See gh-91432: Specialize FOR_ITER python/cpython#91713

It might be worthwhile to get rid of them. Ultimately we will want tagged ints, but that's a long way off.

The first step is to count how many allocations we save by caching the small ints and how many additional calls to PyLong_FromSsize_t we need to make because we can't reuse the left side of an operation, or similar.

One other thing to consider, is whether the expectation that 1 is 0 + 1 is true, is part of the language.
Are we allowed several 0s, or several 1s?

[brandtbucher]

Agreed that this is worth exploring. Perhaps they could be replaced with a free list? I don't think we have one for int yet.

One other thing to consider, is whether the expectation that 1 is 0 + 1 is true, is part of the language.
Are we allowed several 0s, or several 1s?

There are several "fast paths" in the builtins for these sorts of things (range objects optimize for r->step == _PyLong_GetOne() in a few places), but I'm pretty sure that they would still work correctly in the presence of "extra" zeros and ones.

We've added tests in the past (python/cpython#30583, python/cpython#31843) when we've "fixed" small int leaks to make sure we don't regress, but those are always decorated with @cpython_only, which I think puts them firmly in the realm of "implementation detail".

[ericsnowcurrently]

Yeah, it's worth exploring. Also, could we leverage the fact that the small ints are all immortal (e.g. check _Py_IS_IMMORTAL(op) or whatever it will be called).

[gvanrossum]

It's definitely not in the language definition, but I expect that changing this will break a bunch of user code that has always relied on it without realizing it. That user code is wrong, but I don't know how much of it there is. You now get a syntax warning for things like x is 1, but not for x is y.

[kmod]

Just an anecdote -- Pyston v1 had a different set of interned ints than CPython, and we ran into a case where this caused a bug in the Dropbox server due to an integer comparison using "is". It took me a while to determine the issue because it showed up as a logic error that propagated for a while before causing an issue, as opposed to other kinds of compatibility issues which show up as exceptions. Because it was easier to change the set of interned ints than it was to debug a single one of these bugs we just changed our interned ints to be the same as CPython, so I'm not sure if there would have been more issues.

This was before there were static types in the Dropbox codebase, and I'm not sure if that would change the ease of finding these issues.

[sweeneyde]

According to this comment, about 2/3 of ints used are small ints (I don't know how this was measured). Given that, I would guess (I have no data) that keeping around the statically allocated ints is a good idea for the sake of cache locality and fragmentation, but maybe we could keep the static small ints around for some cases but just not use them for other cases, like iterating over ranges?