We need to pick (and add) a licence.

Things will probably be easer to use if we end up representing elasticity as an object with most of the current functions as methods. However, we need to sketch out how this should work. This issue is for this sketch.

At some point check that we can tick the ten rules at: https://arxiv.org/abs/1610.04546

We should have a test case to check the code style matches PEP8. There is a library for this so that should be easy. Obspy has one implementation but we should go much simpler.

It is also worth adding coverage monitoring for the test cases. This blog post outlines how to do this with pytest, but we use nose so that would need modification.

While we are at it, we may want to think about moving from nosetest to pytest (as nose is deprecated) but the test cases would need a bit of work.

We should have some examples. These could mirror the examples in MSAT or could be new. We need to decide if these should be as ipython notebooks or something else.

Ideas below!

One left over feature from the MS_load reimplementation is the ability to 'expand' a limited set of elastic constants to a full matrix. In MSAT this is done in MS_expand. When MS_expand is implemented this feature should be added to the io module.

At some point we should add a developers guide, and this will need to address python 2/3 compatibility. For now, list the main points here and below.

Main points

Try to write in idiomatic python3 with python2 compatibility limited (where possible) to module imports. As far as python2 goes, we only care about 2.7 (which is the only modern python2, and makes things very much easer. Some common issues are listed below.

Print

In python3 we print with a function not a keyword so:

print "Hi!"

becomes:

print("Hi!")

To make this run under python2 we need to from __future__ import print_function at the top of any module where we print.

Strings and bytes

Python3 distinguishes between sequences of Unicode characters (strings) and sequences of bytes (bytes). Dive into python3 provides a good overview. In Python2 strings are ascii and lists of bytes. This means we need to take care about the mode when opening files, and we ought to define string literals as unicode (u"a unicode string") .

The default encoding of python source files is also different (unicode for python3, ascii for python2). To
make unicode OK everywhere, add # -*- coding: utf-8 -*- as the first (or second line, after #!/usr/bin/env python) of all source files.

Testing and developing

We have Travis continuous integration set up to run our tests in a python2 and python3 environment. Try to avoid merging anything that does not pass all tests on both. This means we need to submit changes as pull requests (and get somebody else to review and merge these).

If using anaconda, it is possible to have python2 and python3 environments set up for local development. See https://github.com/andreww/python3_friends/blob/master/introToPython3.md#2-installation for a basic introduction.

The tests on TravisCI fail on Python 2.7 today because we need IPython, and (as of IPython 6.0, released yesterday) IPython needs Python3. We end up with the error recorded at https://travis-ci.org/alanfbaird/PyTASA/jobs/223865304

We have a few options:

1. Stop trying to support python2.7 (i.e. just specify that this needs python3). This would allow us to strip out the bits of compatibility stuff we already have (not much of that, to be honest) and mean that we would never need to depricate python2.7 in the future. However, this may cost us some users... If we do go down this route the guidance at http://www.python3statement.org/practicalities/ will be useful (and should be turned into an issue).

2. Fix this by specifying an older version of IPython. 5.x is a LTS release so this isOK for a few years. However, we don't currently list IPython in requirements.txt (it's just a prerequisite of Jupyter). This is probably possible but (a) a bit of a pain to do and to maintain and (b) would mean that people on python3 may end up downgrading stuff in order to run our code.

3. Implement a workaround in the testing. For example, we could select an alternative file to requirements.txt for the python2.7 tests. Probably easer for us to manage but this could leave us with complex installation instructions for users.

Not a great choice... I do wonder if I've missed something. Worth looking to see how Obspy handle this one.

Views? For now I'll just leave the 2.7 tests broken.