You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Type name varies in the repr() depending on the presence of the C extension #92
This manifests in breakage of BTrees tests when the C extensions are used (they pass when the pure-Python extensions are available).
This is a somewhat common problem. There's a python-dev thread and bpo-issue about this. In particular, in the issue, and one of the PRs that fixes it it's pointed out that getting the correct qualified name in a C type can be complex depending on things like Py_TPFLAGS_HEAPTYPE (and that's just on Python 3, I don't know if there's an equivalent of ht_qualname on Python 2).
Is this a bug here that we should fix, or should downstream consumers be prepared to deal with the difference? In one of my own downstream projects I dealt with the difference. But BTrees already deals with the difference in its own code to produce equivalent reprs in Python as we used to get from C. (See zopefoundation/BTrees#94)
Is there any reason not to fix the instance reprs to avoid this issue?
I'm not quite sure what you mean. If you're asking, "can we make a change to cPersistence.Persistent to report the qualified name", my only answer is "it can be complicated" as discussed in the python-dev thread. Right now it's doing the simplest possible thing (largely because I don't consider myself a C API expert so I kept it simple). If you're asking "can we make a change to persistentce.Persistent to use the simple name", sure, we could, but we lose the module name, which is often useful. (That's a change I could implement.)
I'm not sure how big an issue this really is. BTrees was simple to fix. Still, it's an observable difference.
Activity
Fix tests against persistent 4.4.
jimfulton commentedon Sep 22, 2018
Is there any reason not to fix the instance reprs to avoid this issue?
jamadden commentedon Sep 22, 2018
I'm not quite sure what you mean. If you're asking, "can we make a change to cPersistence.Persistent to report the qualified name", my only answer is "it can be complicated" as discussed in the python-dev thread. Right now it's doing the simplest possible thing (largely because I don't consider myself a C API expert so I kept it simple). If you're asking "can we make a change to persistentce.Persistent to use the simple name", sure, we could, but we lose the module name, which is often useful. (That's a change I could implement.)
I'm not sure how big an issue this really is. BTrees was simple to fix. Still, it's an observable difference.
jimfulton commentedon Sep 22, 2018
IDK :) Perhaps we expose the logical module name (e.g. BTrees.IOBTree.BTree) rather than the actual one.
IDK how big an issue it is either.
Include the module in the C repr
persistent: Autospec creation for update from version 4.4.2 to versio…