Ce lien concerne un module qui ne fait pas partie de Odoo, un module tiers de l'OCA. Je n'ai pas creusé plus que cela, mais probablement un bug dans leur code qui court-circuite l'ORM standard. L'ORM Odoo traite bien les décimal correctement.
Je ne pense pas que ce soit un bug dans le code de l'OCA. En fait, il y a même un commentaire dans le code d'Odoo qui explique le bug: https://github.com/odoo/odoo/blob/12.0/odoo/fields.py#L1334 Dommage que le bug n'ait pas été corrigé depuis sa découvert il y a 3 ans (le 12/4/2016).
Voici un test fait rapidement (sur une branch master-nochange-fp, mais le comportement est le même depuis les premières versions de Odoo): http://tinyurl.com/y263r7cx
J'aurais préféré voir un test unitaire qui garantie la conformité dans le temps et pour tous les cas limite.
De plus j'imagine que le test est fait avec un champ Float et un nombre de décimal hard codé.
Faire cela amène les même désavantages que d'utiliser un float; si tu ne travailles pas avec la bonne précision, il faut alors quantize() manuellement à certains endroits dans le code. (e.g.lors de comparaisons, ou avant de storer, calcul de taxes, ...)
Pas nécessairement, par exemple le cas classique de:
Mais pour moi, c'est une bonne chose que le développeur arrondisse explicitement quand il le veut et doit et que le framework lui dise quand il a oublié.
Le débat revient juste à choisir quel côté du trade-off on préfaire:
- float: performance, flexibilité / facilité de code
- decimal: permettre de gérer des nombres avec plus de 16 chiffres
Pas vraiment. Déjà Decimal n'est pas tellement plus lent (environ 2x) que float en Python3 puisque c'est écrit en C. Pour la flexibilité, Decimal l'est plus puisqu'on peut configurer le context comme on veut alors qu'avec float ça dépend du hardware. Pour la facilité de code, je pense qu'il est justement plus simple que le framework lève des exceptions quand on fait quelque chose de pas correcte qu'il n'essaie de corriger implicitement.
Mais bon, je ne pense pas que j'arriverai à te convaincre car nous ne mettons pas la priorité sur les même objectifs. Je préfère l'exactitude qui peut être quelque fois contraignante à la facilité qui cache des approximations.
PS: je t'invite a chercher sur google "tryton issue quantize" pour prendre du recul --> les deux approches ont leurs inconvénients.
Cette recherche ne donne (à part l'issue Odoo où justement les gens prennent Tryton en exemple pour demander qu'Odoo utilise les Decimal) que 2 issues.
La première est invalide car c'est quelqu'un qui appel quantize sur un dict (on peut parler typage statique avec Python 😉)
La seconde est justement le cas de quelqu'un qui veut utiliser des nombres avec plus de décimal que ce que le context par défaut de Python ne supporte. Donc dans ce cas, il suffit de changer le context pour que ça marche (évidement au détriment de performance).
[^] # 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é à 5.
Je ne pense pas que ce soit un bug dans le code de l'OCA. En fait, il y a même un commentaire dans le code d'Odoo qui explique le bug: https://github.com/odoo/odoo/blob/12.0/odoo/fields.py#L1334 Dommage que le bug n'ait pas été corrigé depuis sa découvert il y a 3 ans (le 12/4/2016).
J'aurais préféré voir un test unitaire qui garantie la conformité dans le temps et pour tous les cas limite.
De plus j'imagine que le test est fait avec un champ Float et un nombre de décimal hard codé.
Pas nécessairement, par exemple le cas classique de:
>>> 0.3 - (3 * 0.1)
-5.551115123125783e-17
n'existe pas avec decimal et sans arrondir:
>>> Decimal('0.3') - (3 * Decimal('0.1'))
Decimal('0.0')
Mais pour moi, c'est une bonne chose que le développeur arrondisse explicitement quand il le veut et doit et que le framework lui dise quand il a oublié.
Pas vraiment. Déjà Decimal n'est pas tellement plus lent (environ 2x) que float en Python3 puisque c'est écrit en C. Pour la flexibilité, Decimal l'est plus puisqu'on peut configurer le context comme on veut alors qu'avec float ça dépend du hardware. Pour la facilité de code, je pense qu'il est justement plus simple que le framework lève des exceptions quand on fait quelque chose de pas correcte qu'il n'essaie de corriger implicitement.
Mais bon, je ne pense pas que j'arriverai à te convaincre car nous ne mettons pas la priorité sur les même objectifs. Je préfère l'exactitude qui peut être quelque fois contraignante à la facilité qui cache des approximations.
Cette recherche ne donne (à part l'issue Odoo où justement les gens prennent Tryton en exemple pour demander qu'Odoo utilise les Decimal) que 2 issues.
La première est invalide car c'est quelqu'un qui appel quantize sur un dict (on peut parler typage statique avec Python 😉)
La seconde est justement le cas de quelqu'un qui veut utiliser des nombres avec plus de décimal que ce que le context par défaut de Python ne supporte. Donc dans ce cas, il suffit de changer le context pour que ça marche (évidement au détriment de performance).