On Sat, 2007-09-22 at 01:24 +0800, Russell Keith-Magee wrote:
> Hi all,
> 
> 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'?

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



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to