The docs say about Field.to_python():
"""
As a general rule, the method should deal gracefully with any of the
following arguments:
* An instance of the correct type (e.g., Hand in our ongoing
example).
* A string (e.g., from a deserializer).
* Whatever the database returns for the column type you're using.
"""
I understand that the first rule is useful when using the SubfieldBase
metaclass, so that ``obj.field = value`` works both for serialized/DB
values and instances of the correct type. Other than this case, is
to_python() called anywhere else in the framework with a value that
may already be of the correct type ? IOW, if I define a custom field
without using the SubfieldBase metaclass, do I still have to handle
converted Python objects ?
The reason I'm asking is that it is not always easy or possible to
differentiate between converted and unconverted values. For example a
field that tries to encode Python objects to JSON doesn't have a way
to differentiate between encoded JSON strings and unencoded strings
that just happen to be valid JSON. All JSONField implementations I
have seen (e.g. http://www.djangosnippets.org/snippets/1478/) use
essentially a best-effort approach, "try to decode it and if it fails
assume it is already decoded", which is generally error prone. I have
a different approach that doesn't use SubfieldBase and expects
unconverted values to be passed in to_python(), so I'd like to know
whether this expectation is always true.
George
--
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.
