There are lots of reasons to use Python for binary work, however the proposal is not application domain specific, it is data type specific to the “numerical tower”.
What makes you think the output of production Python code is not a production C library? One modern example is the MLKEM native library.
output of production Python code is not a production C library
What do you mean by that?
As for your concern on third-party things, as your project grows, you’d find yourself less able to use the standard library only anyway, as versatile as it currently is. The truth is putting anything new into the standard library incurs a maintenance burden. You also have given no response to this point:
All of the intended use-cases are going to have third-party dependencies, so I think it’s fine if this functionality also required a dependency.
Regarding your proposal, is augmented assignment to be supported (__iadd__, __isub__, __imul__, …)? If the integer is mutable, I would expect them to modify the object instead of returning a new one (the current state as per your Copilot-generated draft).
mutableint also isn’t a good name (at least IMO) because I wouldn’t be able to guess that it allows bit access (after all, the more intuitive unit is a byte, by which I mean 8 bits); nor is MutableBitView (a mutable view seems like an oxymoron). Also, your formatting on the top is broken. Another piece of scrutiny I have is that __iter__ is not needed when you have __getitem__; see Built-in Functions — Python 3.14.7 documentation.