Skip to content

Type name varies in the repr() depending on the presence of the C extension #92

Closed

Description

@jamadden

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)

Activity

  1. added a commit that references this issue on Sep 14, 2018
  2. jimfulton commented on Sep 22, 2018

    @jimfulton
    Member

    Is there any reason not to fix the instance reprs to avoid this issue?

  3. jamadden commented on Sep 22, 2018

    @jamadden
    MemberAuthor

    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.

  4. jimfulton commented on Sep 22, 2018

    @jimfulton
    Member

    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.

  5. added a commit that references this issue on Oct 19, 2018
    67447f2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions