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.