-
Notifications
You must be signed in to change notification settings - Fork 28
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
Python 2: OxBTrees allow types as keys; Python 3 does not #153
Labels
Comments
jamadden
changed the title
Python 2: OOBTrees allow types as keys; Python 3 does not
Python 2: OxBTrees allow types as keys; Python 3 does not
Mar 15, 2021
jamadden
added a commit
that referenced
this issue
Apr 7, 2021
Fixes #153. Also take the opportunity to clean up the TODOs in _datatypes.py with regards to checking for default comparison: Use a metaclass so we get caching, and only check for the special methods on the type object.
jamadden
added a commit
that referenced
this issue
Apr 9, 2021
Fixes #153. Also take the opportunity to clean up the TODOs in _datatypes.py with regards to checking for default comparison: Use a metaclass so we get caching, and only check for the special methods on the type object.
jamadden
added a commit
that referenced
this issue
Apr 10, 2021
Fixes #153. Also take the opportunity to clean up the TODOs in _datatypes.py with regards to checking for default comparison: Use a metaclass so we get caching, and only check for the special methods on the type object.
mgedmin
added a commit
that referenced
this issue
Sep 7, 2022
Supersedes and closes #153. (I wonder if GitHub will parse that?)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider:
On Python 3, both
Old
andNew
, which are types, cannot go in the tree because they have default comparison:Under Python 2, however, the default comparison is only detected for old-style classes; new style
type
apparently doesn't have default comparison that we can detect:Type ordering in Python 2 is based on address, making it not suitable for use in a BTree. It emits a warning if you run Python with the
-3
argument.Can we try harder (or just special case) to find that
type
objects shouldn't be used as keys?The text was updated successfully, but these errors were encountered: