Added Decimal to numeric types and allow petl.compat.numeric_types to be customized

[blais]

This PR has two objectives:

1. Make it possible to customize the list numeric_types by late access on the compat module
2. Adding the decimal.Decimal type to the default list of numeric types.

The main purpose is for Decimal numbers to align-right in the vis/look() functions.

Checklist

• I ran the unit tests with tox, for Python 3.9
• I modified the only existing test involving numeric types
• I checked for docs describing numeric types (there are none)

Anything else you need just let me know.

[coveralls]

Coverage decreased (-0.002%) to 91.313% when pulling b75996d on blais:master into 8ee782e on petl-developers:master.

[juarezr]

@blais,

I think it would be nice to have this feature in petl.

I'm wondering if you already have some thoughts on what would be a proper API for unlocking this feature instead of monkey patching?

[blais]

@blais,

I think it would be nice to have this feature in petl.

I'm wondering if you already have some thoughts on what would be a proper API for unlocking this feature instead of monkey patching?

Maybe providing a function to call instead, e.g., add_numeric_types() but then the whole thing could devolve into multiple functions for each of the customizable lists, mirroring a bunch of stuff for basically not every much protection. Personally I think just make those mutable is simpler, but perhaps with some instructions around it. It's a rarity, and in the patch I'm adding Decimal by default anyway. I'd leave it as is. Sometimes no API is the better API, and I think this is one of those cases.

[juarezr]

Yes, I agree.

But I'm wondering if it's worth getting rid of compat like in #478 instead of bothering with this python2 compatibility hack.

Maybe merging the Decimal fix prior to a full source code conversion like #478.
What do you think about it?

[blais]

Yes, I agree.

But I'm wondering if it's worth getting rid of compat like in #478 instead of bothering with this python2 compatibility hack.

Maybe merging the Decimal fix prior to a full source code conversion like #478. What do you think about it?

I think that's beyond my level of involvement with the library so far, it's a decision for the maintainers. My personal view, without the full context around version support expectations, is that yes, Python2 at this stage could be dropped. I mean it's been a very long while now. In any case, a list of numeric types would be required. So in my opinion it's an orthogonal issue.

[juarezr]

Yes, I agree.
But I'm wondering if it's worth getting rid of compat like in #478 instead of bothering with this python2 compatibility hack.
Maybe merging the Decimal fix prior to a full source code conversion like #478. What do you think about it?

I think that's beyond my level of involvement with the library so far, it's a decision for the maintainers. My personal view, without the full context around version support expectations, is that yes, Python2 at this stage could be dropped. I mean it's been a very long while now. In any case, a list of numeric types would be required. So in my opinion it's an orthogonal issue.

As stated in the @alimanfoo petl's author roadmap and in the comments of #563, I think that the move is uncontroversial at this point.

The remaining issue is the lack of manpower for evolving the changes in #563, #336, a few other issues, and fix the packaging to pip, Conda, and readthedocs.org.