On 07/10/2011 06:29, Tai Lee wrote:
Why is ROUND_HALF_EVEN superior? Perhaps for statistics, where
rounding all halves up would skew results, but I guess not for most
other cases.
If the default rounding behaviour produces different results than a
regular calculator, common spreadsheet and accounting software or even
human (mentally adding numbers) would, then I think the default
behaviour is surprising to many users. I was certainly surprised when
I first encountered it, not being familiar with Python's default of
ROUND_HALF_EVEN.
I don't see an easy way for users to change the default rounding
behaviour for `DecimalField`. Would it be considered backwards
incompatible to change the default to ROUND_HALF_UP?
If so, would it be easy enough to make it possible for users to easily
change the default behaviour for a single field or even project-wide?
I think rounding on .save() is not good
even if you could choose which rounding method to use
or if you changed the default method to a more familiar one.
(more on this below)
I hate to suggest adding another setting, but might it be necessary
for some users to change the rounding behaviour of DecimalField that
is defined in a 3rd party app?
Another option you have here is to alter behaviour of your db backend
value_to_db_decimal
You can subclass the backend you're using, then
in settings.py DATABASES['default']['ENGINE'] =
'my_proj.backends.RoundingBackend'
Even monkeypatching the original backend will do the trick.
Or listening for pre-save signals in models with DecimalField
On a related note, the `floatformat` template tag explicitly uses
ROUND_HALF_UP. I think we should at least be consistent. And if
there's cause to allow users to change the behaviour for DecimalField,
they should probably be able to change `floatformat` as well.
I agree that a no_rounding argument would also be good, in addition to
being able to specify the rounding method to use.
ok so the rounding kwarg could be set to 'NO_ROUND', 'ROUND_HALF_UP',
'ROUND_HALF_DOWN', etc...
when, for instance, 'ROUND_HALF_UP' is chosen, rounding should take
place during model validation, this way after calling .full_clean()
all the instance attributes are rounded.
Code in model.clean() will already get the rounded values and
make decisions based on the actual values that will later be stored
in db.
If you choose no rounding (and the digits exceed), then full_clean()
should raise an exception
Letting the rounding happen in .save() is bad and should be avoided whenever
possible
Let me repeat that user input through forms is already checked by
forms.DecimalField
so you won't see any rounding issues for data coming through forms.
The problem arises when instances are created by serializers or whenever
in your code you assign a value to a decimal attribute of a model instance.
Default serializers won't call .save() or send signals or do any model
validation
but data is assumed to be already validated, so I don't see an issue here.
Marco
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
