2.0.4 -> 3.0.12 -> 4.0.1

This is a tale of woe, a tale of migration and tribulation.

I have for many years now been maintaining the integration of Python v2.7 into 
our application using SWIG 2.0.4.  All has been roses.  With the demise of 
Python2, we are of course needing to migrate to Python3.  I have successfully 
(well, I /thought/ successfully) integrated Python v3.8 into our application 
using SWIG 3.0.2.  (Aside:  Why 3.0.2?  Because that's the version that was 
available when I did the initial work, and I have just recently resurrected 
that work from an inactive branch.) Everything looked good, until I attempted 
to run a Python script that interfaces with SWIG Directors.  This otherwise 
battle-tested code triggered an exception in Python 3.8 having to do with 
"PyCheck_Tuple(args)" when my C++ code attempted to execute a Directors function:

     try
     {
         ...
         PCore::LWLayoutGeneric access(l);
         result = plugin->process(&access);
     } catch (...)
     {
         check_python_error();
     }

The "plugin" instance here is a C++ stub class that Python wraps, and which 
the Directors function overrides:

     virtual int process(PCore::LWLayoutGeneric*)
     {
         return AFUNC_OK;
     }

Walking through the SWIG-generated C++ code, the steps are:

1. Swig_Director_IGeneric::process() invokes SWIG_NewPointerObj()

2. SWIG_NewPointerObj() invokes SWIG_Python_NewShadowInstance()

       if (robj && clientdata && !(flags & SWIG_POINTER_NOSHADOW)) {
         PyObject *inst = SWIG_Python_NewShadowInstance(clientdata, robj);

3. SWIG_Python_NewShadowInstance() detects the Python version as being ">= 
0x03000000" and then calls:

     inst = ((PyTypeObject*) data->newargs)->tp_new((PyTypeObject*) 
data->newargs, Py_None, Py_None);

which triggers an assert in the python38 shared library:





Enter SWIG 4.0.1.  I decided to try it as a drop-in replacement for 3.0.12.  
Unfortunately, the import module that it creates does not get the formatting 
correct, leaving indentation errors /all over the module/:





So, of course, I cannot even run the system to see if SWIG v4 solves the 
/original/ issue found in SWIG v3.

As I mentioned, this code was production-tested with Python v2 & SWIG 2.0.4. 
Any insights on what I might adjust to get SWIG v3 to function properly?  Or 
could this be just some kind of bug in that version, and I should focus on 
SWIG v4 when it's working?

_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user