Support string format specification of Money objects

[JakobGM]

Hi, @antonagestam 👋

First off, just want to thank you for publishing this library for the benefit of everyone! I have been looking for a more strictly typed approach to Money-representations in Python for a while now, specifically one that offers a Money type which is generic over the Currency, and immoney seems to fit the bill! 🙇

I'm wondering if you have considered implementing immoney.Money.__format__ in order allow easy human-readable string interpolation of money objects? Our application logic is currently built using stockholm.Money and the m-format classifier is invaluable for use in template rendering, error messages, etc..

If such functionality is not out of scope for this library, perhaps stockholm's implementation could provide some inspiration for how to implement it?

Another thing to perhaps consider if one were to implement such a feature, is the aspect of localization. Should there be some story for how to for instance specify that Euro-amounts should be represented with the currency symbol prepended instead of the currency ticker appended, i.e. printing/interpolating Money(100, EUR) as € 100.00 rather than 100.00 EUR? The localization itself should probably not be provided by immoney, but perhaps an natural extension point should be made available? Anyway, now I'm getting ahead of myself, that is probably an issue for another time.

Thanks, whatever you decide,

• Jakob

[antonagestam]

Hi there 👋

Thanks for reaching out and showing interest in the library. Let me say up-front that I am willing to work together to find solutions for some of the sharp edges that I'm sure exists in the library still.

I'm wondering if you have considered implementing immoney.Money.format in order allow easy human-readable string interpolation of money objects? Our application logic is currently built using stockholm.Money and the m-format classifier is invaluable for use in template rendering, error messages, etc..

No I have not previously considered that. The reason is I have been writing that off as something that should be outsourced to a properly capable localization implementation, and I consider the way py-moneyed handles that to be the way to go. Therefore I also haven't given thought to, or even been aware of, the sort of middle ground formatting you're suggesting. The complexity you're hinting at in the last paragraph is just the tip of the iceberg of doing localization right.

The stockholm formatting spec looks reasonable, and I understand the need for something simple like that for formatting in logging and error messages and similar.

So all in all I'd be willing to accept these changes:

• Adding a some small adapter functionality for babel, similar to py-moneyed.
• Adding a __format__ implementation following the same spec as stockholm.

Is any of this something that you would be willing to work on? The __format__ implementation I could be willing to implement myself at some point, but I couldn't commit to any time-frame for that.

Again, thanks for reaching out, og ha en kjempeflott søndag!

Anton

[antonagestam]

@JakobGM I hope my response made sense, and please let me know otherwise!

[antonagestam]

Since this was merged: #65, I'm now also considering eliminating the need for Decimal in __str__ and __repr__.

[antonagestam]

I've just merged and released the wrapper around babel's formatting I mentioned here, in #73. Together with the improvements to __str__ representation introduced in #70, I think the use cases raised in this issue are covered, although not using the __format__ interface. I'll close this ticket for now, but do feel free to continue the discussion here, and I can potentially re-open this if there's a sufficient reason to do so.