On 12/01/2016 04:13 AM, Alan W. Irwin wrote: >> Spoke too soon I guess. It appears that swig detects which version of >> Python you are using and creates a binding that only works with that >> version. So if you create the bindings in a Python3 environment they >> will not work with Python2 and vice versa. > > I suggest the proper thing for me to do here (post-release since you > are not quite ready yet to merge your Python 3 work, and I am pretty > busy myself) is to have the build system look preferentially for > support for Python 3 + consistent numpy for that Python version, and > if that is not found fall back to looking for Python 2 + consistent > numpy for that version. But the user has the option to skip the look > for that first preference if they so desire. So the approach would be > similar to the way the build system looks first for Qt4, then Qt5 > with the user option to skip the look for Qt4 > except in the Python case the first preference order should likely be the > newer Python (which I assume is completely stable), then the older (as > opposed to the Qt case where the preference order is old, then new for > the reasons I have discussed).
I'm not clear on how cmake detects which version(s) of Python are available, but I would suggest the use of which ever version is currently active, i.e. the one that runs when the user types "python" at the command prompt. If this is Python2 and Python3 is used instead then I think this violates the principle of least surprise. I think we should assume that the user had their reasons for choosing one or the other versions of Python to be active and not over-riding that. Otherwise I predict a lot of questions about why Python fails with: "ImportError: dynamic module does not define init function (init_plplotc)" Which is what will happen when you built with 3 and tried to run with 2. It may also be more difficult to implement because I don't think swig has a flag that allows you to specify which version of Python to use. So to force swig to use the desired Python you'd need to change the users environment so that the desired Python was the active Python. Somewhere in the build process though we should at least report which version of Python (if any) the bindings will be compatible with. >> (3) Based on the make output I think plplot_widgetmodule.c will not >> work with Python3. Is this important? Is there a test for this? > > Yes and yes. The pytkdemo Python script discussed above and for which > I have just implemented the test_pytkdemo target contains the following > import statement: > > from plplot_widget import * > > and is a test of that module (as well as the xNN.py set now, but > hopefully that will be changed to the xwNN.py set soon, see above). Great, thanks! Once you have finished all of your Python changes (and the release) I will rebase my changes and get them working with the changes to the examples and the additional tests you have been working on. -Hazen ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
