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