On Thu, 2007-07-12 at 20:08 -0500, Jeremy Dunck wrote: > On 7/12/07, Collin Grady <[EMAIL PROTECTED]> wrote: > > For instance, if I have an input with name="語" and request.POST > > doesn't support unicode, how do I then get the value for that? :) > > I believe the issue is that *names* for kwargs can not be unicode.
Yes, that's true, but Collin is correct, too, and that's one of the compelling reasons for using Unicode there. Since I've been sucked into responding to this thread, here's the background for the current design (it's not an oversight): The data you get from a form, including the control names is not guaranteed to be ASCII. So the client code either has to get back Unicode or a bytestring and decode it everywhere. After a fair bit of thinking and research (looking at existing uses), I decided that consistency was fairly important and that unless the result is guaranteed to be ASCII in a bytestring, or required to be a bytestring (suitably encoded), Django should always pass back Unicode strings. I was even aware that passing things directly to functions would require some type coercion, but when I sat down and went through everywhere it's likely to be used there were almost no occurrences. Internally, we have to do it in two places (the url template tag and in urlresolvers.py). I also looked through about a bunch of projects on Google code and couldn't find any compelling cases that would be harmed. Almost all the time, passing input args directly to a function is not going to be a good idea. You have to sanitise them anyway, so this inadvertently helps to catch errors. If you truly want to pass in a grab bag of name/value pairs, you can pass them in as a dictionary (i.e. pass in "data", rather than "**data") and you still access it exactly the same way in the function. So, unfortunately, in one or two legitimate cases, people are going to get bitten. I'll update the backwards-compat page and porting guidelines in a moment. The benefits (consistency of data representation) outweigh the disadvantages, though, since this is a rare use-case and can be worked around in one line of code. Regards, Malcolm -- Plan to be spontaneous - tomorrow. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
