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

Plplot-devel mailing list

Reply via email to