Forgot to add :
The problem can be avoided if both set of values are first normalized,
as :
>>> Decimal('0.50').normalize()
Decimal('0.5')
Perhaps this should be internally taken care of, instead of relying on
the user to normalize it?
On Nov 27, 1:04 pm, ethereon <ether...@gmail.com> wrote:
> In brief, a [Typed]ChoiceField can reject a valid choice of type
> Decimal because it is incorrectly compared using smart_unicode.
> Decimal('0.5')==Decimal('0.50') is true, while '0.5'=='0.50' is false.
>
> Verbosely, consider a model defined like so :
>
> class Foo(models.Model):
>
> BAR_CHOICES = (
> (Decimal('0.25'), 'quarter'),
> (Decimal('0.50'), 'unit')
> )
>
> bar = models.DecimalField(max_digits=4, decimal_places=2,
> choices = BAR_CHOICES)
>
> and a ModelForm based on it :
>
> class FooForm(forms.ModelForm):
>
> class Meta:
> model = models.Foo
>
> Now :
> >> FooForm({'bar':'0.50'}).is_valid()
> true
> >> FooForm({'bar':'0.5'}).is_valid()
> false # errors = {'bar': [u'Select a valid choice. 0.5 is not one
> of the available choices.']}
>
> This issue might arise when the choices are dynamically generated, as
> Python isn't rigorous about trailing zeros :
>
> >>> Decimal('1.0') + Decimal('0.5')
> Decimal('1.5')
> >>> Decimal('1.0') + Decimal('0.50')
> Decimal('1.50')
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
