We heard from seasoned developers as well as end-users who had the simplest use case: using DavitPy to load/read SuperDARN data. Topics aired included:
- DavitPy hosting: issue where someone leaves, data inaccessible for weeks. Don’t want that to happen with code. Data should be in archive like Zenodo.
- consider countries with filtered internet. Code mirrored across multiple sites should help in general.
- Breaking up DavitPy into a lean core that strictly handles SuperDARN data and makes basic plots. All else should be in a DavitPy-extras module.
- Some users just want to load the SuperDARN data without using IDL. I noted that a lean DavitPy is amenable for loading transparently into Matlab. That is, Matlab ≥ R2014b can use Python user code, so that it’s transparent to Matlab users how to load the SuperDARN data into Matlab.
Previously, I had made an overly large pull request that incorporated fixes for the issues below. I will make separate, small pull requests for these issues.
Keep install simple
This is a general issue for any Python program, that the
setup.py needs to be as simple as possible.
In particular, keep
install_requires to a minimum, and make use of
extras_require for non-mandatory prereqs.
A working example of a
setup.py using these features is illustrative.
Especially to be avoided are Bash scripts as these don’t work on Windows (unless using Windows Subsystem for Linux).
Python 3 compatible
Users still hanging on to Python 2 are increasingly shrinking in number.
For my own programs, I do not even consider making them Python 2 compatible for several years already.
If a package chooses to support Python 2, use the
six module, making the code Python 3 based.
Example of rich Python 3 exception handling with Python 2 backward compatibility:
import six if six.PY2: ConnectionError = OSError # ... try: # download/upload from server or device except ConnectionError: print('could not connect to device') return
Best practice for forward compatibility: do not use
if six.PY3 or
if not six.PY3, rather use
Require “new enough” Python version
To avoid lots of needless GitHub Issues and emails from users with obsolete Python versions, I have my
set to limit say to Python ≥ 3.5 or whatever your program needs.
See the example