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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
