Return Decimals instead of floats?

[euresti]

Hi. I was playing with the SDK and noticed I was getting float values back from the calls.
This means that if you try to use these numbers you might hit weird floating point math issues.

A quick solution is to add parse_float=Decimal to json.loads would that be possible, or at least configurable?

[phoenixy1]

Hi @euresti, long time no see!

Closing this as it's about the legacy clibs, which we aren't updating any more and we really need to fix this in the API, not the libraries. I'm going to try to get this out in the next api release (which may not be any time super soon).

[jfly]

@phoenixy1 sorry for the necrobump, but I'd be curious to understand this a little more.

It looks like Plaid released a new "sync" api since your message, but as far as I can tell, it says it returns a double. I'm honestly not clear on what that means in the context of JSON, which does not have a double type, just a number type. AFAICT, it's actually perfectly safe for JSON to use JSON numbers as the API does (we're just sending characters over the wire, not floating point numbers), so it feels to me like maybe it's just wrong that the docs say "double" when they should instead say something like "this is a JSON number, be careful about how you parse it to avoid floating point issues".

[phoenixy1]

@jfly ok so the deal is that the docs are generated from the OpenAPI file, which defines Plaid API. Within OpenAPI, double is an accepted format descriptor for a number type. OpenAPI is also used to generate the client libraries. So while pure JSON doesn't have a concept of a double, double is used as a hint to the client libraries to tell them which types to assign to values in the responses, meaning that the double-ness does flow through to client libraries that have a concept of double vs. number (such as Go). For more info on this you can check out https://swagger.io/docs/specification/data-models/data-types/

You're right about this being kind of weird when considered in the context of JSON, and we definitely could modify the docs to override displaying the format values from OpenAPI in favor of something else, or to not display them at all, but in general we haven't seen a lot of confusion on this point and I think what we're currently doing might be the clearest way to present this information.

[jfly]

Thanks for the explanation @phoenixy1. I have 0 experience with OpenAPI, but after reading through their issue tracker, it sounds like an arbitrary precision "decimal" format is something that people keep asking for, and I believe does not exist:

• Additional properties for describing restrictions on number values OAI/OpenAPI-Specification#602
• [REQ] "decimal" format is not supported for "number" OpenAPITools/openapi-generator#2534
• version 3.0: additional formats OAI/OpenAPI-Specification#607 (comment)
• Support for Decimal (monetary) data OAI/OpenAPI-Specification#1519
• this list goes on...

It looks like some people have implemented various workarounds (I think maybe OpenAPI gives you a hook to extend the available formats? I don't know...), but either way, I can understand you not wanted to deal with something nonstandard.

in general we haven't seen a lot of confusion on this point

That is surprising to me. I'd expect anyone who has dealt with floating point imprecision in the past to freak out a little if they find floating point numbers anywhere near currency. I certainly did!

Would you be open to a PR to get this Python library to actually return Decimal instead of floats? It looks like #183 started to try to do that but fizzled out.