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.
setup.cfg should be used to configure the package as much as possible versus
In particular, keep
install_requires to a minimum, and make use of
extras_require for non-mandatory prereqs.
A working example of a
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