the tests allocate about 1GiB as "junk" and then about another 300MiB - this still leaves 8.7GiB usable memory (yes, there's a whole 10GiB available)

without a limit of memory this becomes a completely different (and trivial) kata, and looking at recent solutions most of them use O(n) memory, and even some of the oldest ones do too even if it might have been tighter on memory then (but probably still many times what was needed).

my (presumably invalid) solution strictly speaking only needs 672KiB (1 bit each) or 42MiB with a python list (64 bits per reference)

... should the kata be retired? at best a limit could be set on the process with the resource module and then disallow numpy/mmap but like.. you can still use plain files or if using 672k memory then it's practically impossible to enforce. allocating nearly all of the 10GiB as resident memory takes a lot of time as far as I can tell, and again, still can't reasonably get it below 700KiB, or if just going for that 42MiB mark then it'll break when the environment changes slightly again, such as a different python version or a different vm/container config is used or if another process is changed/added/removed

No tests where the last element in the list is substituted.