The small int cache is -5 to 1024 in 3.15, not -5 to 256

[tamnd]

The most repeated example in every Python tutorial is wrong for the version this project is pinned to.

CPython 3.15 widens the small integer cache from 257 values to 1030. _PY_NSMALLPOSINTS is 1025 and _PY_NSMALLNEGINTS is 5, at Include/internal/pycore_runtime_structs.h:97-98@v3.15.0rc1#_PY_NSMALLPOSINTS, so the cached range is -5 through 1024 inclusive rather than -5 through 256.

Verified, not assumed

Same probe, two interpreters, constructing each integer twice through int(str(n)) so the compiler cannot fold them into one constant.

3.15.0rc1   interned small int range: -5 to 1024
3.14.7      interned small int range: -5 to 256

On 3.15.0rc1, int(str(257)) is int(str(257)) is True. On 3.14.7 it is False.

Why this matters more than one wrong example

It is the whole argument for this project in one line. Every CPython explainer that teaches 256 is 257 was correct when it was written and nothing told the author when it stopped being correct. That is the failure mode the citation checker exists to catch, and this is a live instance of it found on day one.

T08 needs redesigning. The lesson's prediction gate is built on 256 is 256 being True and 257 is 257 being False. On the pin, both are True. The gate still works but the boundary moves to 1024, and the more interesting question becomes why there is a boundary at all rather than where it sits.

It collides head on with #2. Pyodide is CPython 3.14, so a reader running the browser tier gets False for 257 is 257 while the prose, written against the pin, says True. This is exactly the small contradiction that #2 warns destroys trust, and it lands in the first part of the book on one of the first things a beginner tries. T08 cannot ship until #2 has an answer.

What to do

• Rewrite T08's prediction gate around the real 3.15 boundary, and use the 3.14 versus 3.15 difference as the teaching point rather than hiding it
• Make the cached range a number interpolated from a probe script, never typed into prose
• Add a conformance golden that records the exact cached range per version, so the next change to it fails a test instead of surprising a reader
• Feed this into Q2: Pyodide is 3.14 and the pin is 3.15, so how do we handle the delta #2 as the first concrete case the version delta annotation system has to handle
• Check whether any other lesson in Part I rests on a constant that moved between 3.14 and 3.15

[tamnd]

Confirmed on the pinned build and asserted in CI as of #34.

pyxray.obj.small_int_range() probes the bound rather than stating it, by walking outward from zero and building each integer with int(str(n)) so the compiler cannot fold the two occurrences into one constant and make everything look shared. There are three tests behind it. One checks the probe agrees with shares_identity at both edges, one asserts 1024 on 3.15 and 256 on 3.14, and one asserts that 257 is 257 is now a version dependent question rather than a fact.

The negative bound has not moved. It is still -5 on both.

There is a fourth test worth knowing about when T08 gets written, because it is the trap the canonical demo falls into. Two occurrences of the same large integer literal in one compiled unit are the same object, and that has nothing to do with the small integer cache. The compiler stored one constant and both loads point at it. So a lesson that demonstrates the cache with two literals in one cell is demonstrating constant deduplication and calling it something else, on every version, and it would have kept appearing to work after the bound moved.