> Another issue with url_for is the handling of query string parameters
> using keyword arguments. Currently any extra keyword arguments will be
> added to the generated URL as query string, for example:
>
> url_for('/page', arg='val') ==> /page?arg=val
>
> The problem is that you can't use keyword arguments for any of the
> argument names reserved by the function, such as "host", "protocol",
> etc, for example:
>
> params = { 'arg': 'val', 'host': 'machine' }
>
> url_for('/page', **params)
>
> should return:
>
> /page?arg=val&host=machine
>
> but it treats the "host" key in params as the host name so it actually
> returns:
>
> http://machine/page?arg=val
In TG1 we allowed you to either pass kwargs for extra url parmeters or
to pass a params dictionary as a keyword argument, or as the second
positional parameter, so that got around the reserved keyword
arguments problem. Perhaps routes could do something similar...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
