On Mon, Jan 5, 2009 at 12:35 PM, Tycon <adie...@gmail.com> wrote: > > And I dont like the trailing underscore idea, because it would be a > mess to deal with in most common use cases like: > > params = dict(request.params) > url = url_for('/page', **params) > > With the params dict suggestion this will be written into > > url = url_for('/page', params) > > But with trailing underscore you would have to do some ugly (and > expensive) manipulation:
Ah, that's a good point. (Although it has been this way for years and nobody has complained about it till now, so I guess using 'host' as a bona fide parameter is not very common.) So what about having a 'params' argument but keeping the current behavior if 'params' is not set. That would allow backward compatibility. Then if 'params' is set and another argument doesn't correspond to any path variable, I guess you'd raise an error. Wyatt wrote wrote: > > > Actually, I think I like the idea of making the query params into a > > > single argument. It could be a string like a=1&b=2 or a dict. Mike wrote: > > No! Encouraging the user to do their own interpolation and escaping > > would be a step back into the Dark Ages. Wyatt wrote: > Sorry if I'm being daft, but you're only vehemently (!) opposing > ``params`` as a *string*, correct? Correct. Wyatt wrote: > I see your point there, and I can't think of a case where I'd need or want to use a str instead of a dict--except maybe where the query string came from elsewhere, but that seems like a fairly unusual case. Almost always they will come from request.params, which has already parsed them into a dict. Perhaps reading a log file or something. But in general, the parsing to a dict and back is a feature of any good framework, even if it does add some overhead. But that kind of overhead is why you're using a framework in the first place. -- Mike Orr <sluggos...@gmail.com> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---