tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / ...). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.
cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
Ce n'est pas limité à seulement la comparaison à 0 mais à n'importe quelle chiffre et opérateur (>, <, >=, <=).
cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
En fait, le contexte de decimal ne doit pas être mis à jour pour chaque variable. Dans le pratique on définit une fois la précision des calcules intermédiaires (les valeurs par défaut prec=28, Emin=-999999, Emax=999999 sont bien dans la majorité des cas). Et on arrondit le résultat final à la précision attendue.
Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals
Ça dépend ce qu'on appel un bug. Si ne pas avoir d'exception mais un résultat incorrect n'est pas un bug alors oui. Mais à mon avis, il est préférable de détecter les bug en levant une exception mais si le résultat pour le cas courant n'est pas faux.
[^] # Re: float vs decimal
Posté par Cédric Krier (site web personnel, Mastodon) . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 4.
Ça n'a pas l'air d'être vraiment le cas: https://odoo-community.org/groups/contributors-15/contributors-136015
Ce n'est pas limité à seulement la comparaison à 0 mais à n'importe quelle chiffre et opérateur (>, <, >=, <=).
En fait, le contexte de decimal ne doit pas être mis à jour pour chaque variable. Dans le pratique on définit une fois la précision des calcules intermédiaires (les valeurs par défaut
prec=28, Emin=-999999, Emax=999999sont bien dans la majorité des cas). Et on arrondit le résultat final à la précision attendue.Ça dépend ce qu'on appel un bug. Si ne pas avoir d'exception mais un résultat incorrect n'est pas un bug alors oui. Mais à mon avis, il est préférable de détecter les bug en levant une exception mais si le résultat pour le cas courant n'est pas faux.
En fait utiliser des Decimal permet d'avoir un vrai test sur la précision du nombre stocker dans un champs et donc d'éviter la découverte trop tard de problème d’arrondi comme https://odoo-community.org/groups/contributors-15/contributors-136015