Menu

#1104 [Python] wrapper does not compile with python 3.2

closed-fixed
szager
python (260)
5
2011-04-11
2010-09-01
No

Since Python 3.2 (still in alpha), the PyCObject API has been removed, the PyCapsule object is proposed as a replacement.
Swig wrapper code contains calls to PyCObject_FromVoidPtr, PyCObject_AsVoidPtr and PyCObject_Import, and won't compile anymore.
The attached patch fixes the issue and works at least for the wxPython interface, which is quite large and spans several modules sharing the same typesystem.

Of course the changes should be guarded by some lines like "#if PY_VERSION_HEX >= 0x03020000"

Discussion

  • Amaury Forgeot d'Arc

     
  • Olly Betts

    Olly Betts - 2010-09-27

    Haoyu - you're most familiar with the Python 3 support - can you take a look at this patch?

     
  • Olly Betts

    Olly Betts - 2010-09-27
    • summary: wrapper does not compile with python 3.2 --> [Python] wrapper does not compile with python 3.2
    • assigned_to: nobody --> bhy
     
  • Amaury Forgeot d'Arc

    new patch with #ifdefs

     
  • Amaury Forgeot d'Arc

    Here is an updated patch with #ifdef statements:
    #ifdef SWIG_PYTHON_USE_CAPSULE
    This symbol is defined for python versions >= 3.2

    The PyCapsule object is also available in 2.7, but the symbol is not defined there, to avoid potential compatibility issues. Users can define SWIG_PYTHON_USE_CAPSULE if they want (or to test the feature)

     
  • Olly Betts

    Olly Betts - 2010-10-01

    Thanks for the updated patch.

    I've just discovered we have another patch for this:

    https://sourceforge.net/tracker/?func=detail&aid=3047039&group_id=1645&atid=301645

    I've not compared the two yet - just noting this before I forget.

     
  • szager

    szager - 2011-04-07

    Neither patch looks exactly right. This patch has incorrect python version logic to determine whether to use PyCapsule or PyCObject. Here's what the python header files say about version compatibility:

    CObjects are marked Pending Deprecation as of Python 2.7.
    The full schedule for 2.x is as follows:
    - CObjects are marked Pending Deprecation in Python 2.7.
    - CObjects will be marked Deprecated in Python 2.8
    (if there is one).
    - CObjects will be removed in Python 2.9 (if there is one).

    Additionally, for the Python 3.x series:
    - CObjects were marked Deprecated in Python 3.1.
    - CObjects will be removed in Python 3.2.

    From the other patch, this logic looks correct:

    #if ((PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION > 6) || (PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION > 0))

    ... although you might want to add this clause for safety:

    || (PY_MAJOR_VERSION > 3)

    In this patch, in the function SWIG_Python_DestroyModule, I think the call to PyCapsule_GetPointer should use this name:

    (char*)"swig_runtime_data" SWIG_RUNTIME_VERSION ".type_pointer" SWIG_TYPE_TABLE_NAME

    ... rather than:

    (char*)"swig_runtime_data" SWIG_RUNTIME_VERSION

    Note that this patch also blissfully ignores errors:

    if (swig_module == NULL)
    {
    PyErr_Clear();
    return;
    }

    This patch *does* correctly put an #ifdef around the signature line of SWIG_Python_DestroyModule; the other patch does not.

    One thing I think both patches have slightly wrong is that the PyCapsule calls in SWIG_Python_TypeQuery should use a NULL name:

    descriptor = (swig_type_info *) PyCapsule_GetPointer(obj, NULL);
    ...
    obj = PyCapsule_New(descriptor, NULL, NULL);

    Since the PyCapsule isn't being added to a module dict, it's not necessary -- or desirable -- to name it. The python docs explicitly allow a NULL name in such a case.

    With these modifications, I just ran through the test suite using python2.7, and it was clear sailing.

     
  • szager

    szager - 2011-04-11

    I applied the corrected patch to the trunk, revision 12620.

     
  • William Fulton

    William Fulton - 2011-04-11

    Closing as fixed.

     
  • William Fulton

    William Fulton - 2011-04-11
    • assigned_to: bhy --> szager
    • status: open --> closed-fixed
     

Log in to post a comment.