plplot-devel

[Plplot-devel] Python3

[Hazen B. <hba...@ma...>]

Hello,

I would like to fix PLplot so that it works with Python3. At a minimum 
it looks like this means fixing all the print statements, i.e.:

print "asdf" -> print("asdf")

I'll test against Python2.7. Do I also need to test against Python2.6? 
Or is that far enough in the past that we don't support it anymore?

-Hazen

[Plplot-devel] Python3

[Alan W. I. <ir...@be...>]

On 2017-04-17 16:30-0700 Alan W. Irwin wrote:

> Note also that there are additional non-standard Python examples in
> the examples/python subdirectory so those should all be checked to
> make sure they work with both Python 2 and Python 3.  And similarly
> for the pyqt4 and pyqt5 standard examples.

Hi Hazen:

Could you please test commit 578b028?  For that commit I made some
modest progress with Python 3 for both pyqt4 and pyqt5, but I have hit
a roadblock with a run-time error saying the plplot_pyqt[45] extension
modules are not initialized properly when the script tries to import
one of those modules.  The sip, pyqt[45], and python3 software
packages are all supposed to work well together for their latest
versions according to my google search results, but it is possible the
Debian Jessie versions of these software packages are too old and
buggy which is why I am asking you to test this commit by attempting
to build the test_pyqt[45]_example target (depending on whether your
build system finds Qt4 or Qt5) for both the python2 and python3 cases
(where the former builds and runs plplot_pyqt[45] without issues here,
but the latter case only builds these extension modules without
obvious issues but runs into initialization errors at run time).

The test_pyqt4_example target build all
prerequisites with success but fails the final run-time test.

Here is the relevant error message if I attempt to do the
run-time test by hand:

software@raven> python3 examples/python/pyqt4_example.py 
Traceback (most recent call last):
   File "examples/python/pyqt4_example.py", line 33, in <module>
     import plplot_pyqt4
ImportError: dynamic module does not define init function (PyInit_plplot_pyqt4)

Do you get a similar error there or success?

For the record here is the complete list of python3-related packages
I have installed on Debian Jessie.  If you think I am missing anything
please let me know.

software@raven> dpkg --list |grep python3 |cut --delimiter=" " --fields=3
libpython3-dev:amd64
libpython3-stdlib:amd64
libpython3.4:amd64
libpython3.4-dev:amd64
libpython3.4-minimal:amd64
libpython3.4-stdlib:amd64
python3
python3-apt
python3-chardet
python3-checkbox-ng-doc
python3-debian
python3-dev
python3-dugong
python3-magic
python3-minimal
python3-numpy
python3-pkg-resources
python3-pyqt4
python3-pyqt5
python3-sip
python3-sip-dev
python3-six
python3-tk
python3-uno
python3.4
python3.4-dev
python3.4-minimal

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Python3

[Hazen B. <hba...@ma...>]

On 04/21/2017 03:42 AM, Alan W. Irwin wrote:
>
> Hi Hazen:
>
> Could you please test commit 578b028?  For that commit I made some
> modest progress with Python 3 for both pyqt4 and pyqt5, but I have hit
> a roadblock with a run-time error saying the plplot_pyqt[45] extension
> modules are not initialized properly when the script tries to import
> one of those modules.  The sip, pyqt[45], and python3 software
> packages are all supposed to work well together for their latest
> versions according to my google search results, but it is possible the
> Debian Jessie versions of these software packages are too old and
> buggy which is why I am asking you to test this commit by attempting
> to build the test_pyqt[45]_example target (depending on whether your
> build system finds Qt4 or Qt5) for both the python2 and python3 cases
> (where the former builds and runs plplot_pyqt[45] without issues here,
> but the latter case only builds these extension modules without
> obvious issues but runs into initialization errors at run time).
>
> The test_pyqt4_example target build all
> prerequisites with success but fails the final run-time test.
>
> Here is the relevant error message if I attempt to do the
> run-time test by hand:
>
> software@raven> python3 examples/python/pyqt4_example.py Traceback (most
> recent call last):
>   File "examples/python/pyqt4_example.py", line 33, in <module>
>     import plplot_pyqt4
> ImportError: dynamic module does not define init function
> (PyInit_plplot_pyqt4)
>
> Do you get a similar error there or success?

It works for me with Python3 and pyqt5. My understanding is that error 
messages like you are seeing mean that the C library was built for the 
wrong version of Python.

I've attached my CMakeCache.txt file.

-Hazen

Re: [Plplot-devel] Python3

[Alan W. I. <ir...@be...>]

On 2017-04-22 17:55-0400 Hazen Babcock wrote:

> On 04/21/2017 03:42 AM, Alan W. Irwin wrote:
>> 
>> Hi Hazen:
>> 
>> Could you please test commit 578b028?

[...]

> It works for me with Python3 and pyqt5.

Hi Hazen:

That positive test result on your Linux platform is a big relief to
me.  I looked through your previous e-mails, and from one you wrote
last November you were using at that time

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Is that still the case for this test?  If so, that should be
almost exactly a year more modern than my current Debian Jessie
platform (released almost exactly two years ago), and if you have
now moved to a later Ubuntu release that is an even larger disparity
in time of release.

> My understanding is that error 
> messages like you are seeing mean that the C library was built for the wrong 
> version of Python.

That seems like a plausible explanation which I can address by
updating to Debian Stretch (not quite yet ready for official release,
but likely that official release will occur later this year and
Stretch is likely already quite stable enough on my particular hardware
platform, x86_64). Anyhow, I will put that update to Stretch on my
agenda in the intermediate term (within a month or two) even if it
isn't completely polished into an official release by then.

> I've attached my CMakeCache.txt file.

That's somewhat useful information, but capturing the combined stdout
and stderr output from your cmake command, e.g.,

cmake <CMake options> <Top directory for PLplot source tree> >& cmake.out

is even more useful.  That captured output gives the sip (since commit
7f1f5ce earlier today), Python, Qt, and pyqt detailed version numbers.

Also, since the above works for you I have changed (commit 7653e24
today) our default Python version to Python 3 (if it is available) and
Python 2 otherwise.  The Python 3 find is now only skipped if the user
specifies -DFORCE_PYTHON2=ON, but normally they would not want to do
that since Python 3 is likely less buggy than Python 2.  For example,
the Python developer I talked to implied I was very much less likely
to experience the python-generated Plframe.pyc corruption issue that
was showing up for me fairly regularly for Python 2, if I switched to
Python 3, and that expectation has been born out so far in fairly
limited Python 3 testing by me.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Python3

[Alan W. I. <ir...@be...>]

On 2016-11-25 20:30-0500 Hazen Babcock wrote:

>
> Hello,
>
> I would like to fix PLplot so that it works with Python3. At a minimum
> it looks like this means fixing all the print statements, i.e.:
>
> print "asdf" -> print("asdf")
>
> I'll test against Python2.7. Do I also need to test against Python2.6?
> Or is that far enough in the past that we don't support it anymore?

Hi Hazen:

I thoroughly approve of your above goal.

The last release for 2.6.x was in 2013, but some of the key python3
syntax such as print(<string>) were backported to it so by accident it
might still work for us once you are done.  But I suggest for now you
concentrate on python-2.7 (which also includes the same backported
Python 3 syntax) and Python 3.x.

With regard to the bindings, have you seen
<http://www.swig.org/Doc1.3/Python.html#Python_python3support>?  It
appears a very tiny modification (using the -py3 command line option
for swig) of our present python bindings may be all you need to generate
python3 bindings.  So have fun experimenting with that option to
see how far you get!

With regard to the examples, they are really simple python code.
Apparently, there is a script that converts
python2 scripts to python-3 compatibility.  I presume most of what
that script would change would be print statements (to move from the
"print <string>" to "print(<string>)" form).  And with any luck at all,
those new results would work both with python 2.7 (which supports
"print(<string>)" and some other python-3 syntax) and python 3.x.

Good luck with this project!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Python3

[Alan W. I. <ir...@be...>]

Hi Hazen:

P.S.  This further comment assumes that generating a python3 binding
is fairly trivial, i.e., nothing much more than using the -py3 option
to swig. If your experiments confirm that assumption holds, then I
suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
the user sets that to ON, the build system generates and uses a
python3 binding (using, e.g., that -py3 option to swig), and if OFF it
generates and uses a python2 binding (which we will likely want to
support indefinitely in any case).  With that either/or organization
between the two cases, the names of the modules we build will be
identical in the two cases, and the examples should just work
regardless of whether the binding is python2 or python3 (assuming you
can convert the syntax of the examples so that they work both with
python-2.7 and python-3.0).

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Python3

[Hazen B. <hba...@ma...>]

On 11/27/2016 02:51 AM, Alan W. Irwin wrote:
>
> P.S.  This further comment assumes that generating a python3 binding
> is fairly trivial, i.e., nothing much more than using the -py3 option
> to swig. If your experiments confirm that assumption holds, then I
> suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
> the user sets that to ON, the build system generates and uses a
> python3 binding (using, e.g., that -py3 option to swig), and if OFF it
> generates and uses a python2 binding (which we will likely want to
> support indefinitely in any case).  With that either/or organization
> between the two cases, the names of the modules we build will be
> identical in the two cases, and the examples should just work
> regardless of whether the binding is python2 or python3 (assuming you
> can convert the syntax of the examples so that they work both with
> python-2.7 and python-3.0).

The bindings that swig generates are compatible with Python3 as well as 
Python2 without the -py3 flag, so unless it turns out that we absolutely 
need it I'm not going to use it. I also have no plans to add a special 
PLPLOT_USE_PYTHON3 option. I'm reasonable confident we can be agnostic 
here and it will not matter if the Python bindings are built in a 
Python2 environment and run in a Python3 environment or vice-versa.

I would appreciate thoughts on:

(1) In Python2 imp.find_module('_plplotc', ..) will find the shared 
library _plplotcmodule.so, but this fails in Python3. I'm not sure why 
we chose to have a file name that was different from the module name, 
but swig is not generating the right calls for imp.find_module() and 
imp.load_module() to work with this convention in Python3. For the time 
being I have just been editing the generated plplotc.py file by hand to 
fix this. However, unless there is some reason why the C library needs 
to be named _plplotcmodule.so I would like to change its name to 
_plplotc.so, or alternatively change the module name to _plplotcmodule. 
It looks like we are already doing this on windows, the C library is 
called _plplotc.pyd and not _plplotcmodule.pyd.

(2) What is the command line to run a python example in the build tree 
outside of ctest? Some of the examples are failing and debugging would 
be a lot easier if I could run them by hand. Among other annoyances, 
ctest eats any print() output breaking my preferred approach to debugging.

-Hazen

Re: [Plplot-devel] Python3

[Alan W. I. <ir...@be...>]

On 2016-11-27 10:19-0500 Hazen Babcock wrote:

> On 11/27/2016 02:51 AM, Alan W. Irwin wrote:
>> 
>> P.S.  This further comment assumes that generating a python3 binding
>> is fairly trivial, i.e., nothing much more than using the -py3 option
>> to swig. If your experiments confirm that assumption holds, then I
>> suggest you should define a CMake option called PLPLOT_USE_PYTHON3. If
>> the user sets that to ON, the build system generates and uses a
>> python3 binding (using, e.g., that -py3 option to swig), and if OFF it
>> generates and uses a python2 binding (which we will likely want to
>> support indefinitely in any case).  With that either/or organization
>> between the two cases, the names of the modules we build will be
>> identical in the two cases, and the examples should just work
>> regardless of whether the binding is python2 or python3 (assuming you
>> can convert the syntax of the examples so that they work both with
>> python-2.7 and python-3.0).
>
> The bindings that swig generates are compatible with Python3 as well as 
> Python2 without the -py3 flag, so unless it turns out that we absolutely need 
> it I'm not going to use it. I also have no plans to add a special 
> PLPLOT_USE_PYTHON3 option. I'm reasonable confident we can be agnostic here 
> and it will not matter if the Python bindings are built in a Python2 
> environment and run in a Python3 environment or vice-versa.

It is good to hear it is likely going to be even easier than I thought.  I
guess that -py3 flag is needed for more complex Python bindings than ours.

>
> I would appreciate thoughts on:
>
> (1) In Python2 imp.find_module('_plplotc', ..) will find the shared library 
> _plplotcmodule.so, but this fails in Python3. I'm not sure why we chose to 
> have a file name that was different from the module name, but swig is not 
> generating the right calls for imp.find_module() and imp.load_module() to 
> work with this convention in Python3. For the time being I have just been 
> editing the generated plplotc.py file by hand to fix this. However, unless 
> there is some reason why the C library needs to be named _plplotcmodule.so I 
> would like to change its name to _plplotc.so, or alternatively change the 
> module name to _plplotcmodule. It looks like we are already doing this on 
> windows, the C library is called _plplotc.pyd and not _plplotcmodule.pyd.

I have looked at the naming conventions used in practice for
python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
of inserting a "module" suffix on the basename of the shared object
has mostly (but not completely) fallen out of favour.  So it is fine
with me if you drop the module part of the shared object name as well.

>
> (2) What is the command line to run a python example in the build tree 
> outside of ctest? Some of the examples are failing and debugging would be a 
> lot easier if I could run them by hand. Among other annoyances, ctest eats 
> any print() output breaking my preferred approach to debugging.

Try,

make test_python_psc

>From what you say, this will fail with python3, but the important
issue is it will build all python prerequisites and run each
python example up to the first that fails with python3.  Let's say
that first failure was for standard example 00.

Then, you can run that example individually
(_in the build tree_) as follows:

examples/python/x00 -dev psc -o test.psc

Then edit examples/python/xw00.py in the _source tree_ (to make sure
your changes are not lost), copy that changed version by hand to the
build tree (or else run "make test_python_psc" to do that) and try
again running it as above until you are satisfied with your source
tree change.  Then move to the second example that fails at run time
as revealed by "make test_python_psc", etc.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Python3

[Hazen B. <hba...@ma...>]

On 11/27/2016 01:40 PM, Alan W. Irwin wrote:
> It is good to hear it is likely going to be even easier than I thought.  I
> guess that -py3 flag is needed for more complex Python bindings than ours.

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 have looked at the naming conventions used in practice for
> python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
> of inserting a "module" suffix on the basename of the shared object
> has mostly (but not completely) fallen out of favour.  So it is fine
> with me if you drop the module part of the shared object name as well.

I just changed the output target from _plplotcmodule to _plplotc. Maybe 
this will have some downstream consequences?

> Try,
>
> make test_python_psc

..

> Then, you can run that example individually
> (_in the build tree_) as follows:
>
> examples/python/x00 -dev psc -o test.psc

Thank you, this was very helpful.

The Python bindings are now compatible with Python3 as well as Python2, 
as judged by running the (basic?) tests, i.e.

$ make
$ ctest

New questions:
(1) How does one run the tests that compare the example output files to 
each other so that I can verify that the output is still the same?

(2) There appear to be at least two versions of each Python example. 
Maybe we could get rid of one set? i.e. the xNN.py set and not the 
xwNN.py set that are actually tested?

(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?

If anyone is interested, my python3 branch is available here:
https://github.com/HazenBabcock/PLplot/tree/python3

Just for testing though, don't do any work off of it :).

I'm going to wait until after the release to push this into master as 
the changes were somewhat intrusive and are likely to have broken something.

-Hazen

Re: [Plplot-devel] Python3

[Alan W. I. <ir...@be...>]

On 2016-11-30 20:59-0500 Hazen Babcock wrote:

>
>
> On 11/27/2016 01:40 PM, Alan W. Irwin wrote:
>> It is good to hear it is likely going to be even easier than I thought.  I
>> guess that -py3 flag is needed for more complex Python bindings than ours.
>
> 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.

Hi Hazen:

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 have looked at the naming conventions used in practice for
>> python-2.6 and python-2.7 on Debian, and even there the old-fashioned idea
>> of inserting a "module" suffix on the basename of the shared object
>> has mostly (but not completely) fallen out of favour.  So it is fine
>> with me if you drop the module part of the shared object name as well.
>
> I just changed the output target from _plplotcmodule to _plplotc. Maybe this 
> will have some downstream consequences?

I don't believe this is a concern. That doubly raw C module should be
effectively private, i.e., it should only be imported by the swig-generated
plplotc.py module (which we already designate as the raw module).  That in turn is
imported by the hand-crafted module plplot.py which is the one
that users would prefer to import. So I don't think there will be any
downstream consequences other than in the lists of filenames that are
part of creating a software package (i.e. an rpm or deb) for PLplot,
but packagers typically have access to packaging tools to automatically
deal with changed filenames that are installed so I don't think even
that is going to be a downstream issue.

>> make test_python_psc
>
> ..
>
>> Then, you can run that example individually
>> (_in the build tree_) as follows:
>> 
>> examples/python/x00 -dev psc -o test.psc
>
> Thank you, this was very helpful.

You are welcome.

>
> The Python bindings are now compatible with Python3 as well as Python2, as 
> judged by running the (basic?) tests, i.e.
>
> $ make
> $ ctest

Good news, indeed!

>
> New questions:
> (1) How does one run the tests that compare the example output files to each 
> other so that I can verify that the output is still the same?

ctest does that already with its examples_compare test (which depends
on the various tests named examples_<binding> which run our standard
set of <binding> examples using -dev psc).  I think you need the
--extra-verbose option to see the results of that test on stdout, but
I also believe even without that option you can see the results of that
test in the Testing hierarchy of directories.

> (2) There appear to be at least two versions of each Python example. Maybe we 
> could get rid of one set? i.e. the xNN.py set and not the xwNN.py set that 
> are actually tested?

You ask interesting questions!  The situation concerning the largely
unmaintained xNN.py set and the well-maintained 
and xwNN.py set is summarized in examples/python/README.pythondemos.
At the time when I wrote that, I was hoping that Geoffrey Furnish (who
was the author of the plplot_widgets module and the pytkdemo example
that used that module + Tkinter + our own Tcl/Tk plframe GUI) would
consolidate the two sets of examples, i.e., by teaching the
well-maintained xwNN.py set how to be run from pytkdemo.

Well, Geoffrey dropped out of PLplot development soon after and there
it rested until you asked your question above.  :-)

To start to answer your question I have just implemented a test of
pytkdemo (see commit cb2a2c6) which is the test_pytkdemo target, and
that target build and resulting GUI appear to work fine subject to
some bugs in the xNN.py set of examples (see lack of maintenance
comment above).  Also, to look further at the consolidation question I
looked carefully at x10 + xw10.py (the combination used to run that
example for the pure python case versus x10.py, and it turns out the
only real difference is the namespace one which is straightforward to
deal with.

So I tried the appropriate namespace changes for x10 and xw10.py, and
the result is xw10.py can be called directly from pytkdemo, and the
combination of x10 and xw10.py still works perfectly for the pure
python case! With this proof-of-concept under my belt, I plan to
continue this work for all 33 of the xw??.py (replacing as needed in
pytkdemo or adding there when the corresponding x??.py does not
exist).  Which after a lot of editing and careful testing should allow
me to throw out the xNN.py set and rename the xwNN.py set as xNN.py.
(The "w" in the xwNN.py historically stood for "widgetless", but I
have long realized that choice of mine was a poor one which I would
like to get rid of in the way suggested.)

That change would be a most welcome addition for this release, but all
that editing required for the namespace change will likely be quite
time consuming.  But I will see how far I get with this tomorrow
(Thursday) to help decide whether I will be able to get this complete
topic merged into master before the freeze date this weekend.

> (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).

More later.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Python3

[Hazen B. <hba...@ma...>]

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