-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bitarray should be a subtype of frozenbitarray #212
Comments
Hey, I also wonder how the relationship between the Python I will give this some more thought. Please let comment on this issue if you have more ideas about this topic. And please open a new issue if you have other thoughts about the 3.0 release. One idea I have is to rename the |
Rather than open any new issues I'll just make some observations here and let you decide if they merit their own issues. These might just be personal to me so I hope I don't sound too critical. Some are breaking changes and some are not:
[And if you follow the bytes/bytearray naming then Hope those suggestions / observations are useful. Thanks. |
Thank you for all the remarks. Here are some of my thoughts:
|
That all looks good to me. I agree that it's probably not good to parse initialisation strings to see if they are hex or bin etc. as that could add an unavoidable overhead for everyone. One other wrinkle I've only just noticed is that |
Good catch! I remember adding sub_bitarray search to |
@scott-griffiths I'm planning a 2.9 release in the next few days. Everything for the release if in Let me know what you think. Thanks |
Looks good. My one comment is that the I notice that the |
Thanks! I've updated the documentation for the Yes, I added sub_bitarray to |
Bitarray 3.0 is released now and I have decided against making |
Hi,
A feature suggestion to consider as I see you're preparing a 3.0 release, and this would be slightly backward incompatible.
At the moment
frozenbitarray
is a subclass ofbitarray
, so is essentially abitarray
which has had various mutating methods removed from it. The more natural arrangement (for me) would be to havefrozenbitarray
be the base class and havebitarray
be a subclass that adds the mutating methods.This is a breaking change as for example
isinstance(some_bitarray, bitarray.frozenbitarray)
would becomeTrue
instead ofFalse
, but I'd argue that this is less surprising behaviour.The real reason for doing this is that it could allow a
frozenbitarray
object to perhaps be simpler (and thus faster) than abitarray
object. Trivial example: a copy method wouldn't have to make a copy but could return the original object as an optimisation.I don't know how realistic this is as I appreciate that it might be a real chunk of work, but I think switching their relationship around would allow for some future optimisations.
Thanks. 👍
The text was updated successfully, but these errors were encountered: