1) No way, at the very least we need unicode params. 2) Meh... I like this one the best of the 3 3) This breaks compatibility with Turbogears, but I had to do the same thing with DBSprockets to support unicode.
Option 4: I have another option which might work well. Keep things the way they are in TG1 for regular strings, but add a new optional parameter called params which collects all of the params. **kw should continue to work however. That way functions can keep their same signature, but still have the ability to support unicode_params... I think a deprecation warning should be in the code for this so we can eliminate the **kw later (but i have no idea how we are going to throw this error). This way people won't gripe about this problem when moving from TG1 to TG2, then we can get rid of **kw in subsequent releases Option 5: Doesn't Python 3.0 solve everything? ...Maybe we should just go to that :-P. cheers. -chris On Mar 5, 7:21 am, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > Unicode is awesome. Unicode sucks. > > OK, now that I've got that off my chest, here's the deal. The fact > that TurboGears turns incoming request prams into controller function > params seems intuitive and smart to me. But there are some > limitations: > > * Function params must have asci string names > * Function params can have only one value > > The second issue is not really that big of a deal, because how often > do people use the fact that HTTP params can be multi-valued? And we > provide request.params (a unicode multi-dict) just in case you need to > get at the full set of params. > > But the first is a common enough issue that I think it could be a > problem for TG2, because it could cause unexpected behavior. In Py3k > this will not be an issue anymore because we'll be able to use unicode > characters in python identifiers. > > I see three solutions, and we are using the crappiest of the three. > > 1) use the non-unicode multi-dict from the request to determine the > params. This is what we're doing now because it was quick and easy. > The downside is that both the param names AND the params themselves > are asci strings. > 2) convert just the keys of the Unicode params to asci and blow up if > something goes wrong... > 3) pass in the Unicode Multi-Dict as a params dict rather than as > individual parameters. > > I think 3 is probably the "best" answer, becuse it also solves the > multi-value issue, and it will always work, but it's a backwards > incompatible change. To mitigate that, we could have a switch > convert_params=True in the environment setup of TG2. When it's on we > could do 2 and when it's off we could do 3. But I'd very much like > to make sure that there's one "right" way to do it, and not end up in > a place where users are doing things in two very different ways. On > the other hand, practicality beats purity. > > What do you all think? > > -- > Mark Ramm-Christensen > email: mark at compoundthinking dot com > blog:www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
