#14317: numberformat.format produces wrong results
-------------------------------------------+--------------------------------
Reporter: akaariai | Owner: akaariai
Status: new | Milestone:
Component: Internationalization | Version: 1.2
Resolution: | Keywords: Localization,
number formatting
Stage: Unreviewed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------------+--------------------------------
Changes (by akaariai):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
After this patch, the working of number_format is as follows:
- if given too large number, will return it in exponent format
- if given too small a number and no decimal_pos, will return it in
exponent format
- if given decimal_pos, will return the number correctly rounded
Before this patch:
- if given too large number, would return it in exponent format
(possibly mangled with thousand separator), it the number was float, else
in correct format.
- if given too small number and number_pos, would return the number in
1e-10,2, which is a bug
- if given too small number and no number_pos, would return the number
in exponent format (possibly mangled with thousand separator)
- never did any rounding.
The main disadvantage of this patch is that large int, decimal and string
numbers will be returned in exponent format, whereas before they were
returned in correct format. Also, small numbers passed as strings when not
using number_pos would be correctly returned. Now they are returned in
exponent format.
So, all in all, the behavior is more consistent now, as any number passed
in, no matter in what type, will be returned in same format. On the other
hand, this means loss of correct formatting for some number types. If
correct formatting for large numbers passed as strings or decimals is
wanted, it gets a bit messy to achieve that and correct decimal_pos
handling at the same time. It would at least require different formatting
paths for strings and other types.
A simple fix for the bug described in the original report is to test if
'e' is in unicode(number) and if it is, return the e format directly...
Oh, BTW after this patch number formatting should be a bit faster (0% to
almost 50% depending on what is being formatted). 1/3 of time is used in
testing settings. (It seems a bit strange to me that number_format is
testing any settings, but that is another matter.)
--
Ticket URL: <http://code.djangoproject.com/ticket/14317#comment:1>
Django <http://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 post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
