[serhiy-storchaka]

Add prime-number functions to the math.integer module, supporting integers less than 2**64 (larger arguments raise OverflowError, leaving room to extend support to larger integers later in a backward compatible way):

• isprime(n, /) -- deterministic Miller-Rabin primality test (bases {2, 7, 61} below 4759123141, Jim Sinclair's seven bases up to 2**64, verified against the Feitsma-Galway list of base-2 strong pseudoprimes). The result is always exact.

• primes(start=2, stop=None) -- iterator of the primes in [start, stop), unbounded if stop is None, with O(1) memory.

• Issue: Add math.integer.isprime() and math.integer.primes() #153222

🤖 Generated with Claude Code

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33465270 | 📁 Comparing 81e40f0 against main (3a1b547)

  🔍 Preview build  

3 files changed

± library/math.integer.html
± whatsnew/3.16.html
± whatsnew/changelog.html

[github-actions]

This PR is stale because it has been open for 90 days with no activity.

[StanFromIreland]

This has a lot of conflicts.

I suggest deferring primes() to a follow-up. primes() is currently algorithmically the same as (p for p in itertools.count(start) if isprime(p)). And, while the C iterator saves some overhead, it a small constant factor. It also greatly complicates this PR and the implementation. As such, I simply think that the limited benefit is not worth it. I think that if we ever want a fast prime iterator it should be designed as a sieve from the start, but that should be left to a later discussion.

I'm happy to review isprime() once those points are resolved, I think it's a reasonable addition.

CC @mdickinson

[StanFromIreland]

I wrote a slightly modified implementation giving a nice speedup (also drops math.integer.primes()): #160678