General Folder Structure

[LinguList]

Apart from re-arranging, I think we'll still have the following structure:

• algorithms/ reserved for algorithmic procedures that are used by dfferent methods, partially supporting cython
• sequence: package for sequence handling, not comparison, including all cleaning functions
• align: package for sequence comparison
• wordlist: package for wordlist and etymological dictionary handling (basic input format)
• compare: package for handling comparative routines in wordlists
• trees: package for extended tree handling, based on python-newick
• phylogeny: package for handling tree-clilmbing stuff etc., like Sankoff-Parsimony (code already there)
• misc (?): package for writing files to different formats
• data: package for data-handling

The names are not really important, but the responsibilities: handling sequences, wordlists, and trees, both as an object of itself, and in comparison, seems important for me.

[xrotwang]

Two comments:

1. I'd rather not put code into the data directory. E.g. the code related to initializing a sound class model from the spec files should go into a classmethod SoundClassModel.from_path.
2. I would hope there is not that much wordlist related code. If so, I'd rather have a top-level wordlist.py module, providing one class Wordlist.

[LinguList]

I agree. So data/ would just be reserved for data, and sound-class handling, including those sound-class-models, would go into the sequence package (the term "model" has anyway confused many people, and it seems just that the sequence/ folder would be the right place for this).

[SimonGreenhill]

I worry that misc tends to become a code bloat magnet! If it's mainly for output, then why not have output for writing to things. Anything else "misc" should be kept as a plugin/addon or given its own top level.

[LinguList]

I agree. Given output, we will have to offer quite some things anyway, as I think it is important to, e.g., offer output to nexus, phylip, csv, etc. So having one clean output module/package is surely a good idea. What we would discard and put into a plugin are the plots, which can't be really sufficiently tested and are mostly "on your own risk". I love doing things with matplotlib, but I hate to be made responsible for insufficient output by users.