Skip to content
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

Closed
jamadden opened this issue Mar 15, 2021 · 0 comments · Fixed by #163
Closed

Python 2: OxBTrees allow types as keys; Python 3 does not #153

jamadden opened this issue Mar 15, 2021 · 0 comments · Fixed by #163

Comments

@jamadden
Copy link
Member

Consider:

class Old:
    pass

class New(object):
    pass

from BTrees import family64
bt = family64.OO.BTree()

On Python 3, both Old and New, which are types, cannot go in the tree because they have default comparison:

>>> bt[Old] = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Object has default comparison
>>> bt[New] = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Object has 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:

>>> bt[Old] = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Object has default comparison
>>> bt[New] = 1

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?

@jamadden 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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant