Skip to content

[C API] Make the PyDescrObject structure opaque: PyDescr_NAME() and PyDescr_TYPE() #90696

Closed

Description

@vstinner
BPO 46538
Nosy @vstinner
Files
  • pydescr_set_type.patch
  • pydescr_new.patch
  • pythoncapi_compat_pydescr_new.patch
  • swig_pydescr_new.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2022-01-26.16:23:19.541>
    created_at = <Date 2022-01-26.16:14:46.779>
    labels = ['expert-C-API', '3.11']
    title = '[C API] Make the PyDescrObject structure opaque: PyDescr_NAME() and PyDescr_TYPE()'
    updated_at = <Date 2022-01-26.16:35:59.571>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2022-01-26.16:35:59.571>
    actor = 'vstinner'
    assignee = 'none'
    closed = True
    closed_date = <Date 2022-01-26.16:23:19.541>
    closer = 'vstinner'
    components = ['C API']
    creation = <Date 2022-01-26.16:14:46.779>
    creator = 'vstinner'
    dependencies = []
    files = ['50585', '50586', '50587', '50589']
    hgrepos = []
    issue_num = 46538
    keywords = ['patch']
    message_count = 7.0
    messages = ['411765', '411766', '411767', '411768', '411769', '411770', '411773']
    nosy_count = 1.0
    nosy_names = ['vstinner']
    pr_nums = []
    priority = 'normal'
    resolution = 'rejected'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue46538'
    versions = ['Python 3.11']

    Activity

    1. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      While working on the PEP-674 implementation, I noticed that PyDescr_NAME() and PyDescr_TYPE() macros are used as l-value by two projects: M2Crypto and mecab-python3. Both are code generated by SWIG.

      M2Crypto-0.38.0/src/SWIG/_m2crypto_wrap.c and mecab-python3-1.0.4/src/MeCab/MeCab_wrap.cpp contain the function:

      SWIGINTERN PyGetSetDescrObject *
      SwigPyStaticVar_new_getset(PyTypeObject *type, PyGetSetDef *getset) {

        PyGetSetDescrObject *descr;
        descr = (PyGetSetDescrObject *)PyType_GenericAlloc(SwigPyStaticVar_Type(), 0);
        assert(descr);
        Py_XINCREF(type);
        PyDescr_TYPE(descr) = type;
        PyDescr_NAME(descr) = PyString_InternFromString(getset->name);
        descr->d_getset = getset;
        if (PyDescr_NAME(descr) == NULL) {
          Py_DECREF(descr);
          descr = NULL;
        }
        return descr;
      }

      ref: https://bugs.python.org/issue45476#msg407410

      SwigPyStaticVar_new_getset() is more of less an outdated copy of Python 2.7 descr_copy() of Python Objects/descrobject.c.

      I tried to prevent using the PyDescr_NAME() and PyDescr_TYPE() macros as l-value in two ways:

      • Add PyDescr_SET_NAME() and PyDescr_SET_Type()
      • Add PyDescr_New()

      The problem of the PyDescr_SET_NAME() and PyDescr_SET_Type() approach is that SWIG code is outdated: it doesn't initialized the PyDescrObject.d_qualname member added to Python 3.3 (bpo-13577, commit 9d57481).

      So I implemented PyDescr_New() function: in CPython, it means basically to rename descr_new() to PyDescr_New(). Problem: implementating this function for older Python versions is non trivial. Code that I wrote for the pythoncapi_compat project:

      // bpo-45476 added PyDescr_New() to Python 3.11.0a5
      #if PY_VERSION_HEX < 0x030B00A5
      PyDescrObject *
      PyDescr_New(PyTypeObject *descr_type, PyTypeObject *type, const char *name)
      {
          assert(descr_type != NULL);
          assert(type != NULL);
          assert(name != NULL);
      
          PyObject *name_obj;
      #if PY_MAJOR_VERSION >= 3
          name_obj = PyUnicode_InternFromString(name);
      #else
          name_obj = PyString_InternFromString(name);
      #endif
          if (name_obj == NULL) {
              return NULL;
          }
      
          PyDescrObject *descr = (PyDescrObject *)PyType_GenericAlloc(descr_type, 0);
          if (descr == NULL) {
              Py_DECREF(name_obj);
              return NULL;
          }
      
          
          descr->d_type = (PyTypeObject*)Py_NewRef(type);
          descr->d_name = name_obj;
          // PyDescrObject.d_qualname was added to Python 3.3.0a1
      #if PY_VERSION_HEX >= 0x030300A1
          descr->d_qualname = NULL;
      #endif
          return descr;
      }
      #endif

      The even more complicated part is to write unit tests for this function in pythoncapi_compat. It requires to implement a whole type with tp_traverse tp_dealloc functions.

      In Python, this function must be at least documented.

      At the end, IMO it's not really worth it to add so much complexity to Python and pythoncapi_compat just for 2 projects using SWIG. I created this issue to keep a track of my analysis, if someone else tries to do something similar tomorrow.

      I attached my WIP patches to keep a copy of this work, in case if we need to revisit this idea later.

      For the PEP-674, IMO it's better to leave the two PyDescr_NAME() and PyDescr_TYPE() macros unchanged. There is no need in the short term to make PyDescrObject structure and structures using it opaque in the short term. Well, SWIG code looks incorrect (it doesn't initialize d_qualname), but a fix just for SWIG should be enough.

    2. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      pydescr_set_type.patch: Python patch to add PyDescr_SET_TYPE() and PyDescr_SET_NAME() functions.

    3. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      pydescr_new.patch: Python patch adding the PyDescr_New() function.

    4. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      pythoncapi_compat_pydescr_new.patch: pythoncapi_compat patch adding PyDescr_New() function with tests.

    5. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      swig_pydescr_new.patch: SWIG patch adding PyDescr_New() and using it.

    6. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      Since making PyDescrObject opaque is not really worth it, I close this issue.

      I mean, it's worth it, but there are more important structures like PyObject, PyTypeObject or PyListObject.

    7. vstinner commented on Jan 26, 2022

      @vstinner
      MemberAuthor

      The problem of the PyDescr_SET_NAME() and PyDescr_SET_Type() approach is that SWIG code is outdated: it doesn't initialized the PyDescrObject.d_qualname member added to Python 3.3 (bpo-13577, commit 9d57481).

      I checked: Oh, in practice, it's not an issue since PyType_GenericAlloc() initializes the memory to zero. So the code "just works".

    8. changed the title [-][C API] Make the PyDescrObject structure opaque[/-] [+][C API] Make the PyDescrObject structure opaque: PyDescr_NAME() and PyDescr_TYPE()[/+] on Jan 26, 2022
    9. changed the title [-][C API] Make the PyDescrObject structure opaque[/-] [+][C API] Make the PyDescrObject structure opaque: PyDescr_NAME() and PyDescr_TYPE()[/+] on Jan 26, 2022
    10. transferred this issue fromon Apr 10, 2022
    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

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions