Repository navigation
update examples to python 3 #208
Description
Activity
Here is another depreciaton warning in the step function
MatplotlibDeprecationWarning: pyplot.hold is deprecated. Future behavior will be consistent with the long-time default: plot commands add elements without first clearing the Axes and/or Figure. plt.hold(True) /usr/local/lib/python3.5/dist-packages/matplotlib/__init__.py:805: MatplotlibDeprecationWarning: axes.hold is deprecated. Please remove it from your matplotlibrc and/or style files. mplDeprecation) /usr/local/lib/python3.5/dist-packages/matplotlib/rcsetup.py:155: MatplotlibDeprecationWarning: axes.hold is deprecated, will be removed in 3.0 mplDeprecation)Thanks, I see there are a few Python-2-style prints; for the record just search for "print " in examples/. That is an easy fix: you're welcome to submit a PR for that.
On the Matplotlib deprecation warnings, we've started fixing them, see, dc1820a -- we could extend this idea to the other plot types. This is a a slightly trickier job.
See also mail thread here https://mail.python.org/pipermail/matplotlib-users/2018-January/001256.html where some Matplotlib experts gave advice on this topic. This would amount to a new set of plotting routines, and is a big job.
I did a bit of work on this. Tried running all the example scripts with Python 3.7.3 and fixed any tracebacks that I found (a few old
printstatements, removed thehold()functions, and added a fewshow()functions so that plots would appear if the user ran the script from the terminal).Is that all that was needed? Shall I make a pull request?
You'll need to make sure that the changes work across all versions of python that we currently support (2.7, 3.6, 3.7), if you haven't already. The main thing here will be making sure nothing breaks in 2.7. The easiest way to do this is to set up your own repository to use Travis CI and then you'll get the same unit test runs on your local commits.
Once you are ready, send in the PR and we can take a look.
Okay thanks, I am now getting Travis CI set up and running. I will hopefully have a PR with an updated set of examples soon...
There is already a
.travis.ymlfile in the repository, so you don't need to add anything. Once you push your code fork up to GitHub, it should trigger a Travis CI run.The one other thing you need to do, if you haven't already, is to put in a "webhook" that will tell GitHub to send info to Travis CI when you push changes to your repository. To set that up, go to Settings → Webhooks on your copy of the repository and add the Travis CI webhook.
Thanks @murrayrm ! It is working now. They started automatically as soon as I pushed it. B.t.w. do the tests include testing the examples?
Yes, the Travis CI tests include all of the unit tests (in
control/tests) as well as all of the examples (inexamples/). Note that if you are doing local testing usingpython setup.py testsyou only get the unit tests. You can run the tests on the examples by running therun_examples.shscript inexamples/.Okay, three of the tests failed and I'm trying to figure out how to see why. It shows a job log and at the very bottom it says:
Running secord-matlab.py No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received The build has been terminatedIs this why it failed?
(The three that failed were the ones where
SCIPY=scipy SLYCOT=slycot)Yes, that's probably the issue. If you send a link to the Travis CI build, I can have a look.
One easy thing to check is that there is no user input required in the examples, since that will case Travis CI to "hang". You can use the environment variable
PYCONTROL_TEST_EXAMPLESto check whether the example is running inside a script (this variable is set inexamples/run_examples.shand then make sure not to block for that case.An example is at the bottom of
examples/phaseplots.py(and several other files), where the end of the file has the codeif 'PYCONTROL_TEST_EXAMPLES' not in os.environ: show()This makes sure that the
matplotlib.pyplot.showcommand (which blocks) is not called if you are running as a script.Also, the reason that this only shows up for the
SCIPY=scipy SLYCOT=slycotcase is that we require SLYCOT in order to run the examples (see code toward the end of.travis.yml).Okay so
secord-matlab.pyis one of the scripts I updated. I did addshow()methods because I thought that was a good idea. (See here).Not sure how I'm supposed to share it but can you open this link to the Travis log: https://travis-ci.com/billtubbs/python-control/builds/114835576
So, should I not use
show()then and use the if statement above instead?There's a suggestion here to use a function decorator to patch the show() function during testing (from the
unittest.mockmodule). Would this be a better solution here?Looks like the
showstatements are the problem. You can either:-
Put a single
showcommand at the bottom of the file. -
Leave a
showat the end of each group of commands (as you have it). -
Change the
showcommand to be nonblocking (show(block=False)) and see if that works.
If you leave in a blocking show, then you need to do put in the short
ifstatement so that it doesn't block when you run Travis CI.You can try using the decorator, but I think that has to be in front of a function (or class method), so may not work well in this instance.
-
The single
showat the bottom will still hang it up. So I think it's a question of what we want these examples to be used for from a user's perspective.If we take out all the show commands then when the user executes the scripts from the command-line, nothing happens:
$ python secord-matlab.py $If these examples are simply code that we expect users to inspect and maybe edit and adapt to their needs then this behaviour may be fine. But if we are expecting novice users to execute the code and expect to see the figures then this is a bit confusing.
Another option might be to do something like this at the end of each script:
# Uncomment this line to see the plots #show()I'm happy to do whatever works best.
Wherever you put a
showcommand, you need to add the if statement to stop it from hanging up on unit tests.Really up to you on the examples. People have done it both ways and I think the examples get used both by people trying to see how to do things (inspecting the code) and also people trying out the toolbox (so running the code).
Another alternative we have been playing with is using Jupyter notebooks (see
ipynbfiles), but these are not run in the unit tests.Okay I used the
if 'PYCONTROL_TEST_EXAMPLES' ...method in the end as it was already being used in a few places. Made a lot of edits to make things more pythonic and PEP compliant such as removing semi-colons, adding spaces, changing indenting, and removing things likefrom numpy import *. May upset a few die-hard Matlab users who like having every possible function in the global namespace...Looks like it passes the Travis tests so shall I submit a PR now?
Fixed in PR #307
Hi, it is mainly about the print brackets for python3.
Also, as many examples do not show the actual plot, I recommend to use
import matplotlib.pyplot as pltat the beginning and put aplt.show()at the end.Otherwise, it is hard for newbies to know what is going on.