#22171: sanitize_separators throws away too many thousand separators
-------------------------------+--------------------
Reporter: vanschelven | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.4
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
Users in countries that use symbols other than the period (e.g. comma) as
a decimal separator, may still occasionally use the period as a decimal
separator. (Because they've come to expect that computers want input with
a period). If the period coincides with the THOUSANDS_SEPARATOR, and
USE_THOUSANDS_SEPARATOR is turned on, this results in the decimal
separator basically being thrown out, but still with a validated result.
Example shell output (THOUSANDS_SEPARATOR == '.'; USE_THOUSANDS_SEPARATOR
= True)):
{{{
>>> from django.utils.translation import activate
>>> activate('nl-nl')
>>>
>>> class F(forms.Form):
... f = forms.DecimalField(max_digits=15, decimal_places=2)
...
>>> f = F({'f': '10.10'})
>>> print f.is_valid()
True
>>> print f.cleaned_data['f']
1010
}}}
Why does this happen? django/utils/formats.py has a function
sanitize_separators, that basically tosses all thousands separators ''even
if they do not actually separate thousands''
My solution would be to only toss thousands separators which have at least
3 digits on their right hand side.
Admittedly this is not a full solution: the value 100.000 is still
ambiguous if we assume that users may mean either "thousands separator" or
"decimal separator" with the period. But at least it does not silently
convert 10.00 (which doesn't mean 1000 to anyone) into 1000. This solution
also happens to cover all scenarios where cents are involved, which
A better solution would not validate "10.00" at all (since it does not
contain either a decimal separator nor a thousands separator separating
thousands). However, the current interface of sanitize_operators does not
allow for it: it attempts to sanitize towards a string w/ period, and does
not allow us to complain if the input is a string w/ period, but we
wouldn't want to allow that as a valid input.
The/a solution for Django 1.4 is attached. I imagine it may be a bit more
hairy in the up-to-date version, as this supports full unicode for the
input, and I'm not entirely sure on the interaction of regex & unicode.
I've reproduced this in 1.4, but can see in the repo that as of today the
code still experiences this problem.
--
Ticket URL: <https://code.djangoproject.com/ticket/22171>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/054.8863bb2f0e89d641c6cd8573eb16f97d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
