{{{
class CustomForm(forms.Form):
field = forms.IntegerField(initial=42)
form = CustomForm()
print(type(form['field'].value())) # int
form = CustomForm({'field': '42'})
print(type(form['field'].value())) # str
}}}
`form['field']` is `IntegerField`, but it returns string, when you pass
data from POST/GET (which are usually strings). It even returns string,
when you pass `initial='42'` (which is odd also). The problem is with FKs
in `ModelForm`: the value in unbound form is int (from database), but in
bound form it's string (from POST).
I've checked source code and `BoundField.value` uses
`Field.prepare_value`, which is undocumented and (except for
`DateTimeField`) it just returns original value.
I would expect, that `value` is always data type defined by `Field`, which
is done in `to_python` method.
Questions are:
1) Is it bug or feature?
2) Should I use `to_python` instead, when I want "consistent" type of
field value?
3) What's the meaning of `prepare_value`?
--
Ticket URL: <https://code.djangoproject.com/ticket/21045>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I don't think Django provides any guarantees regarding the field value
types before the form is validated; for example, by calling `is_valid()`.
--
Ticket URL: <https://code.djangoproject.com/ticket/21045#comment:1>
Comment (by jcatalan):
As far as I understand from the value method
[https://docs.djangoproject.com/en/dev/ref/forms/api/#django.forms.BoundField.value
doc] this method its meant to return the initially provided value, so if
it was a string in the GET/POST dict, I guess it's ok if value returns a
string. Or am I missing something.
If it's ok, maybe we should close this one as wontfix?
--
Ticket URL: <https://code.djangoproject.com/ticket/21045#comment:2>
* status: new => closed
* resolution: => invalid
Comment:
Yes, I don't think there's a bug here.
--
Ticket URL: <https://code.djangoproject.com/ticket/21045#comment:3>