More flexible rename map

[xrotwang]

It would be cool, if the rename command was a bit more flexible in how it accepts the rename map. Since it requires the mapping to be specified in a file, it would seem natural - for example - to accept a CSV file and either treat the first two columns as mapping spec, or - even better - allow passing in column names for source and target of the mapping. This would allow us to run phyltr rename on D-PLACE phylogenies and the associated taxa.csv files.

[xrotwang]

Of course the question is where to stop - what about tab-separated files? But I'd say python's "default csv dialect" would be a reasonable compromise.

[lmaurits]

Yeah, this makes a lot of sense. It probably wouldn't even be too hard to use the csv module's Sniffer class to handle tab-separated files gracefully.

Of course, this should be done systematically over all commands which accept details from a file, so that phyltr as a whole is as consistent as possible.

[xrotwang]

True. Should I have a go and send a PR?

[xrotwang]

Btw. - and I think we discussed this somewhere before - what about dropping py2 support? CSV reading is unfortunately one of the corners of python where py2 and p3 are icompatible ...

[lmaurits]

Sure, feel free (to have a go)!

I'll think on the py2 thing. My initial reaction was "Eek!", but after some reading, and being reminded that PSF support for 2.7 basically only has 6 months left anyway, perhaps it's finally time to make changes like this...

[SimonGreenhill]

Kill it! 2.7 is dead! :)

[lmaurits]

I still carry the scars from my first postdoc, where the lab's number crunching machine was some old OS X rig that nobody had root access to and that didn't have any Python 2 version above (I think) 2.5 installed! This is why I've generally been stubbornly slow about things like, e.g. switching from optparse to argparse. But I suppose we can't support everything forever. Let's do it!

[xrotwang]

@lmaurits of course you're in for the next decision: Which minimal version of py3 should we support? I've seen the recommendation a couple of times that starting with 3.4 is reasonable (in particular when just porting from py2). This would work for us, too, since e.g. statistics was added in 3.4. Also 3.4 has shipped already with Ubuntu 14.04. For some of our packages we require >=3.5 because 3.5 is where pathlib was reasonably complete. But in phyltr file handling isn't a big issue.

[xrotwang]

Python 3.3 support is already deprecated in tools like pip (see pypa/pip#3796), so I think it comes down to deciding between 3.4 and 3.5.

[xrotwang]

I also use textwrap.shorten to truncate sub-command docstrings for the command overview. That's new in 3.4, too.

[lmaurits]

Well, I'd still like to err on the conservative side of things, to the extent that it doesn't make life difficult for us. If we're not currently using any features exclusive to 3.5, I see no reason not to support 3.4, at least to begin with.