Use Babel for all formatting

[kvesteri]

Hi! Thanks for great package. There is a lot of overlapping functionality here with Babel. Why not adding Babel as a requirement and make number formatting and currency stuff use babel? Babel is the defacto i18n library in Python so it makes sense to use it rather than inventing the wheel again.

[limist]

Thanks, that's a good suggestion, from what I see of Babel it's indeed the standard - would you like to make-it-so via a pull request? :)

[spookylukey]

Babel does look like a good option, except that now the project looks a bit dead:

https://github.com/mitsuhiko/babel

• no updates for more than a year, no response from the maintainer to about 100 issues and pull requests. New release python-babel/babel#158

[spookylukey]

Babel now has a new maintainer it seems, who is looking after it well.

Babel relies on CLDR for all its info, and we should definitely be using it for all our currency formatting, rather than having to review and manually merge PRs for every single locale.

This would be a significant piece of work, but would massively reduce maintenance needs in the future, and solve a whole bunch of issues, and even the need to think about what is the right behaviour, because Babel/CLDR already has a standard answer.

I think the right approach to all requests for new locales is to instead wait for a patch for this issue. To be concrete:

Almost the whole of moneyed/localization.py needs to be deleted/rewritten. Only the format_money function needs to remain, because that is a documented function, but it should be using babel.numbers.format_currency. We should try to maintain backwards compatible with its output, but if babel has more correct algorithms or defaults it's OK to have some small changes.

For those who just need a specific locale to be added, and don't want to wait for this to land, here is a reminder that you can install from your own github branch:

https://pip.pypa.io/en/stable/reference/pip_install/#vcs-support

[spookylukey]

Actually, I had a much better idea than my last comment:

1. Deprecate the whole of moneyed/localisation.py. Usage of format_money should raise a DeprecationWarning

2. Introduce a new format_money function (possibly in moneyed/l10n.py or something new) with a new API which is simply a very thin wrapper around babel.numbers.format_currency

[tardate]

+1

I was just looking for exactly this i.e. round to a "human" value supported by the currency. I noticed a similar idea but differing implementation approach suggested on #47

I wonder if there are actually three behaviours that should be supported:

• by default, unrounded, i.e. for precise financial calculations e.g. $13.123456 or ￥20.123
• rounded to the smallest conventional/human value i.e. for a price list e.g. $13.12 or ￥20
• rounded to the smallest cash value e.g. our smallest coin is 5 cents, so while a price may be $13.12, the actual amount charged is $13.10 (seems Use Babel for all formatting #22 & babel won't actually address this?)

[spookylukey]

@tardate - the last one on your list seems too specific to a particular application. It can always be implemented externally in your own code.

[spookylukey]

For the sake of clarity on where this issue is up to:

1. We are no longer accepting updates to the list of countries and currencies, or formatting of currencies. This is a never ending task, and we should instead be getting this data from CLDR. Thankfully there is already a Python wrapper for this in the form of Babel, we just need to use it. All PRs and issues relating to fixes or additions to the countries/currencies will be closed in favour of this issue.

2. The solution we are waiting for looks like this:

• The whole of moneyed/localisation.py will be deprecated. Usage of format_money should raise a DeprecationWarning

• babel will be added as a dependency.

• There will be a new format_money function (possibly in moneyed/l10n.py or something new) with a new API which is simply a very thin wrapper around babel.numbers.format_currency, obviously it should handle Money objects as input.

3. I have no intention of working on this, and there are no other active maintainers - this is waiting for a patch from someone else.

[spookylukey]

Latest work is in #136