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.
I don’t think that such type deserves to become part of the Python built-in types. It’s rarely used for specific use cases. For example, I never needed such type. To add a type to Python, you should convince other developers that it’s widely used and show examples where it’s already being used.
I don’t think that such type would be useful for cryptography or compression, C or Rust code is usually preferred for that. I don’t see how embedded systems are supposed to use the type.
There are already battle tested PyPI modules like BitVector or bitarray (using ba2int() and int2ba() functions). You use one of these. If these projects don’t cover your use cases properly, you’re free to create your own project on PyPI.
Whatever ..
Making it a python object, implicitly makes it accessible. Making it mutable, means you can actually do anything more than mere augmented assignment of whole integers. Hence mutable (instead of immutable) is the primary benefit, worthy of distinction in the name.
The Cython specification, of course gives us “bints”, but that’s in fact c not Python.
Maybe what you want already exists: mutableint · PyPI
What does “accessible” mean here? You have responded to none of my points.
Thanks.
Shame no stats.
The correct question is “How would you wish bits to be accessible, or addressable?” If you came to the question in this way, you would be extremely unlikely to conceive of anything as restrictive as augmented assignment operators as the model answer.
The Pythonic way for interacting with variables, is variable length, slicing, splitting, indexed, perhaps sorted , automatically extending etc, none of which are available today for a bit, or [sequence, list, dictionary of bits]. This is thanks to no one having sensibly questioned the formulation of a numerical tower in PEP3107, bowing down to a single author from Google Inc. Nothing on the web exists below one byte, but that is such limiting and application domain specific view point.
A related question is how should the language best represent a qubit?
Let us be clear, I have no obligation to respond at all. It is always a choice.
Let’s also be clear, no-one here has an obligation to consider your proposal, and the core devs have no obligation to implement it (or accept a PR if you submit one). The responsibility is very much on you to persuade people that your idea is worth pursuing if you want anything to happen here.
So far, your arguments haven’t been that persuasive (to me, at least) and your style of interaction doesn’t encourage me to take any interest in the proposal.
I think that is getting off-topic. Bits and qubits are physically different. Mentioning this question here cannot convince others to accept your proposal or move the discussion.
A sequence/list of bits can be achieved with bitarray as mentioned above. A dictionary of bits can be achieved with {0: 1, 1: 1} or with frozenbitarrays + bitarrays (depending on which one you’re trying to refer to).
Adding new Python features adds maintenance burden (e.g. fixing bugs, maintaining backward compatibility when adding other features) and so far I don’t feel convinced that this feature is worth those efforts.
I’m REALLY not impressed by your debating style, especially since PEP 3107 neither has a single author nor is talking about the numerical tower. I don’t even know what your point is in this, other than to claim that Python is somehow under the thumb of a corporation and every single core dev is abdicating their responsibility to the project in favour of letting Google control things.
(And if you folks are getting kickbacks from Google, where’s my share???)
This no longer appears to be going in a productive direction.