[Django] #21045: BoundField.value doesn't use to_python

10 views
Skip to first unread message

Django

unread,
Sep 5, 2013, 7:59:05 AM9/5/13
to django-...@googlegroups.com
#21045: BoundField.value doesn't use to_python
----------------------------+--------------------
Reporter: Elvard | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+--------------------
The problem occures when using data from POST in bound form:

{{{
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.

Django

unread,
Sep 5, 2013, 1:42:10 PM9/5/13
to django-...@googlegroups.com
#21045: BoundField.value doesn't use to_python
------------------------+--------------------------------------

Reporter: Elvard | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
------------------------+--------------------------------------
Changes (by timo):

* 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>

Django

unread,
Sep 6, 2013, 5:40:11 PM9/6/13
to django-...@googlegroups.com
#21045: BoundField.value doesn't use to_python
------------------------+--------------------------------------

Reporter: Elvard | Owner: nobody
Type: Bug | Status: new
Component: Forms | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
------------------------+--------------------------------------

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>

Django

unread,
Sep 9, 2013, 10:58:00 AM9/9/13
to django-...@googlegroups.com
#21045: BoundField.value doesn't use to_python
------------------------+--------------------------------------
Reporter: Elvard | Owner: nobody
Type: Bug | Status: closed
Component: Forms | Version: 1.5
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0

Easy pickings: 0 | UI/UX: 0
------------------------+--------------------------------------
Changes (by timo):

* 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>

Reply all
Reply to author
Forward
0 new messages