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
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.
In [1]: u='語'.decode('utf-8')
In [2]: {u:1
Passing raw GET params into a function seems like a recipe for
disaster if you fail to validate something properly.
Plus, unicode is allowed to be used as get/post keys, so not
supporting it in the dict keys would cause problems.
For instance, if I have an input with name="語" and request.POST
do
trings make sense.
> for example, what if the keys contain non-ascii data?
>
> > This seems like a bug, possibly overlooked, but having unicode keys
> > prevents certain functionality like **request.GET in a method call.
>
> hmmm.. well, you can always convert it, can't you
ery good reason for the opposite.
and in this case, it seems to me that unicode strings make sense.
for example, what if the keys contain non-ascii data?
> This seems like a bug, possibly overlooked, but having unicode keys
> prevents certain functionality like **request.GET in a method ca
Is there any reason why its storing the keys in QueryDict (possibly
others) as unicode?
This seems like a bug, possibly overlooked, but having unicode keys
prevents certain functionality like **request.GET in a method call.
--~--~-~--~~~---~--~~
You received
