force_unicode(strings_only) and DateTime objects
Russell Keith-Magee
I've been looking at #5553 [1] tonight; it looks to be a good patch to
fix some Datetime serialization issues that have arisen recently.
[1] http://code.djangoproject.com/ticket/5553
It's a fairly small change, but I'm still coming to terms with the
finer points of the unicode changes, so I wanted to get a sanity check
that I wasn't going to do something with unexpected consequences.
force_unicode() provides the strings_only option, which allows you to
convert an object to a unicode string, leaving 'non-strings'
unmodified. In this context 'non-strings' are specifically defined as
NoneType, int and long.
The proposed patch modifies this list of non-strings, adding DateTime,
Time and floats.
Is there any particular reason that smart_unicode checks explicitly
for int, long and None? Would there be any side effects to adding
DateTime, Time and float to the list of 'non strings'?
Yours,
Russ Magee %-)
Malcolm Tredinnick
That should be fine.
The main thing we don't want to do there is try to check for basestring
or derivatives. There are things that are coercable to strings, but need
a little help in order to ensure they are encoded correctly (they are
string proxies in our use-cases). We *want* to (and must) be able to
transparently handle objects that know how to convert themselves to a
string representation (i.e. they have a __str__ and/or __unicode__
method).
Ideally, smart_unicode() would behave exactly like str() or unicode()
and they don't have special cases for any types at all. However, that
turned out not to be possible in practice, because it's much cleaner to
be able to call smart_unicode or force_unicode in some places where we
don't want to convert certain types to string form (the exceptions list
in that method). All attempts to do without the exceptions led to hard
to handle problems elsewhere.
Fortunately, the ugliness is contained in a small corner. There are only
a very small handful of cases where strings_only=True is needed, so we
can live with it.
Regards,
Malcolm