NF: allow truncated last track in trackvis file

[matthew-brett]

From report on mailing list by Carolyn D. Langen - trackvis reader was giving
TypeError when trying to read file where last track was shorter than declared
in the 'n_points' data.

Allow this situation for the last track with new 'errors' kwarg.

This is a slight API break because:

• We are now raising a DataError if there are too few streamlines in the
  file, instead of a HeaderError;
• We are raising a DataError if the track is truncated, rather than a
  TypeError when trying to create the points array.

[matthew-brett]

Question - is errors={'strict', 'lenient'} the best way to name the kwarg?

What do people feel about the API break? Break is that this code returns different errors to the previous code.

[effigies]

To avoid an API break, one option is errors={'strict', 'lenient', 'original'}, make 'original' the default and raise a deprecation warning. (Where 'original' could also be some more sensible name.)

If breaking the API is fine, and only two modes are needed, then any reason not to do strict={True, False}?

[matthew-brett]

I was thinking that we might want to allow different set of errors to pass, in the future, which might have different strings, or even lists specifying the errors that can pass. Might be a bit much though.

[matthew-brett]

OK - I went for strict=True|False as you suggested. We can always tune this by allowing strings or lists as values in some future extension.

I think the API change is OK, it's pretty minor, and I think the errors should be DataError.

[matthew-brett]

Is this one OK to merge? Any other comments here?

[effigies]

LGTM.

Edit: I'm assuming you tried this on the .trk files the reporter posted to the list? It'd be good to get a confirmation from her that it works for her use cases, but don't know you can count on that.

[matthew-brett]

Chris - yes - this does load the file the reporter shared...