Reconsider asserts

[dopplershift]

I really like the Defensive Programming unit, but I'm of the opinion that you may want to consider teaching assert as a tool for validating user input. For one, explicit errors like ValueError are more descriptive of the problem rather than the generic AssertionError. The other problem is that if you run python as python -O or python -OO (which is short for setting PYTHONOPTIMIZE=1), all assert statements are ignored/compiled out. In general, assertions are supposed to be used to double check conditions that should never occur, not for validation of user input. Some other posts around this:

• https://dev.to/yloganathan/do-not-abuse-the-assert-1cfm
• http://archive.is/5GfiG

Just my $0.02.

[DamienIrving]

Good point, @dopplershift. From what you've seen of the plot_precipitation_climatology.py script, are there more authentic/appropriate places we could use assertions? (There's currently three assertions in the final version of the script.)

If we can't think of an appropriate use case for assertions in plot_precipitation_climatology.py, we could also consider using the example in the Software Carpentry defensive programming lesson. There are some nice post-conditions in that example where assertions check that the calculated result is within sensible bounds.

We could also introduce catching and handling errors using try/except in the defensive programming section?

Note to self: We should also get rid of the rainfall observations loop at the beginning of the defensive programming chapter and just use assert np.min(rainfall_obs) >=0.0, because we literally just finished the vectorisation chapter where we talk about avoiding loops.

[dopplershift]

Honestly, 95% of my use of assert is when writing tests. I used to use them to sanity check conditions in I/O code, but I've replaced that with logging and trying to continue--it's not helpful to users when your assert needlessly causes reading a file to completely crash out a script.

I think assert does have it's place, but I don't think it's something critically important for scientist programmers to know. Much more important, IMO, is error handling with try...except and raise. Also provides an opportunity to introduce them to reading tracebacks... :wink:

[CristinaUrizar]

For quality controlling code, I believe that assertions can be helpful. Though, I have some suggestions on some of the wording and would also like to suggest another objective.

Oftentimes, meteorologists and oceanographers operationalize their code (run it every day at the same time, for example) to analyze data as it comes in. The assertions can be directed to a log file that tracks the code accuracy (I suggest "accuracy" rather than "reliability" in this context) each time it runs.

Failure to generate a new log file (that may, or may not, include the output from the assertions), or a new entry in the log file, indicates a failure of the code to run. This is oftentimes referred to as "reliable" code.

I would suggest "How can I check my programs' accuracy?" for the lesson question rather than "How can I make my programs more reliable?"

That being said, I would leave both questions and introduce the Objective "Create log files to verify my program's reliability."

As an operational oceanographer who is new to Python, this would be very beneficial to me and my colleagues.

[DamienIrving]

"Assert is removed with compiling to optimised byte code (python -o producing *.pyo files)."

https://bandit.readthedocs.io/en/latest/plugins/b101_assert_used.html

[DamienIrving]

Just FYI to anyone on this thread who might be interested - I've done a re-write of the defensive programming lesson taking on board all your feedback. See #55 for details.