Re: [Plplot-devel] Python3
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.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 __ -- 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
Re: [Plplot-devel] Python3
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 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 # This is the CMakeCache file. # For build in directory: /home/hbabcock/Code/plplot-build # It was generated by CMake: /usr/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. # EXTERNAL cache entries //Add extra source-tree consistency checking targets that require // special tools ADD_SPECIAL_CONSISTENCY_CHECKING:BOOL=OFF //Enable build of DocBook documentation BUILD_DOC:BOOL=OFF //Build doxygen documentation BUILD_DOX_DOC:BOOL=OFF //Build Hershey fonts? BUILD_HERSHEY_FONTS:BOOL=OFF //Build shared libraries BUILD_SHARED_LIBS:BOOL=ON //Compile examples in the build tree and enable ctest BUILD_TEST:BOOL=ON //Build the testing tree. BUILD_TESTING:BOOL=ON //Path to a program. BZRCOMMAND:FILEPATH=BZRCOMMAND-NOTFOUND //Path to a program. CAMLIDL:FILEPATH=CAMLIDL-NOTFOUND //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //Ada compiler CMAKE_Ada_COMPILER:FILEPATH=/usr/bin/gnatgcc //Flags used by the compiler during all build types. CMAKE_Ada_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_Ada_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_Ada_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_Ada_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_Ada_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //Choose the type of build, options are: None(CMAKE_CXX_FLAGS or // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_BUILD_TYPE:STRING= //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //C compiler CMAKE_C_COMPILER:FILEPATH=/usr/bin/cc //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release builds for minimum // size. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds. CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during release builds with debug info. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds.
Re: [Plplot-devel] Python3
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
Re: [Plplot-devel] Python3
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_ which run our standard set of 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
Re: [Plplot-devel] Python3
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 -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Python3
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
Re: [Plplot-devel] Python3
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
--
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Python3
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 __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] python3
On 2010-10-27 09:41-0600 Orion Poplawski wrote: Has any thought been given to supporting python3? Fedora now ships python3 alongside python and numpy now has a python3 module. Hi Orion: Your question inspired me to google for python2 versus python3 differences, and I found http://www.dwheeler.com/essays/python3-in-python2.html. That essay notes the lack of backwards compatibility and resulting all-or-nothing transition demanded by python3. The conclusion is that python3 uptake has been slowed because of this problem. I also compared http://qa.debian.org/popcon.php?package=python3-defaults and http://qa.debian.org/popcon.php?package=python-defaults. According to those statistics python3 has about 1 per cent of the python2 usage for Debian users. My guess is that the popularity of python3 over python2 will take a long time to be established and may never be complete. On the other hand, python3 usage is definitely here now and growing, and it solves some fundamental issues with the python2 language. Thus, it would be a shame if python3 users were forced to go without PLplot for too much longer. My conclusion is we should support both python2 and python3 similarly to the way we support both Fortran 77 and 95. Implementing that should be straightforward. According to http://ctrl-c.us/blog/archives/99, swig-1.3.37 or later (Debian testing already has swig-1.3.40) supports python3 so we could do a lot of the work by copying bindings/python to bindings/python3 and examples/python to examples/python3 while applying the 2to3 script where appropriate to convert our python2 scripts to python3 syntax. Of course, the devil is in the details so there would presumably be a lot of such details to sort out before we really had working python3 bindings and examples. There are quite a few other projects that are on my PLplot agenda at the moment, and I also need to spend some substantial time with the FreeEOS project in the near future. So I estimate it would be a long time (probably from 6 months to a year) before I could tackle the above myself. Thus, I hope somebody else here (whether you are a core PLplot developer or just getting started with PLplot development) jumps in before me if you have an interest in python3. 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); PLplot scientific plotting software package (plplot.org); 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 __ -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
