Framework for adding input/output formats

[gwerbin]

Right now, the list of formats is more or less hardcoded into the formats.available tuple, and it's not straightforward to extend (at least not to me).

It would be great if you could subclass an abstract Formatter class, and then either have it magically register (using some kind of metaclass magic, I suppose) with the available formats list or introduce a function and/or class decorator to explicitly register the new format.

Is that something you'd be interested in working on in the near term? I'd be happy to contribute some of my own time for it.

[iurisilvio]

I'm looking for a good solution to this issue and really want it done.

Ideas?

[gwerbin]

Ok. Unfortunately I've gotten a lot busier recently and won't have time to look at this until well into the new year. I'll post an update when I've had a chance to size up the task.

[iurisilvio]

No problem. I'm still trying to decide the best API for it.

Based on your suggestions:

• I don't like the subclass magic register
• I like the class decorator idea

I tried to make formats available per dataset/databook instance, but it creates some complicated problems.

Also, I started a solution this way:

from tablib import formats
formats.register("zip", MyFormatter)

We can do the same thing with decorators.

I'll finish my work and push it to a branch to receive some feedback.

[LaundroMat]

I'd like this, because I'm using a lot of different locales (where comma's are one time used as thousand separators and sometimes as decimal indicators). Any update on the progress?

[gwerbin]

Looks like we both might have forgotten about this a bit. I don't have any time now to work on this unfortunately.

[claudep]

The PR #395 converts all formats to classes, with a registration pattern. This should allow to easily add custom formats. I think I was able to not (or minimally) break the current tablib API. I would be very interested to get input about the chosen approach.

[iurisilvio]

I don't think you need to enforce classes there. If the .register receive the object instead of the class (or at least check if it is a class or a module), the current way would still work.

[claudep]

You are probably right, but I think using classes gives much more power to the customization ability, and can save code too. See for example the new tablib/formats/_tsv.py. You can easily subclass any tablib format, and just customize the attribute or method you need.
I will still explore your suggestion to accept an instance instead of a class.

[hugovk]

@gwerbin @iurisilvio @LaundroMat Please could you review PR #395? Thank you!

[claudep]

I'd like to go forward with this issue. I would have much appreciated more reviews, but I guess we can still polish this refactoring in master before the next release. Any opposition?

[claudep]

This is now in master.