Sylvain Hellegouarch wrote:
> Luke Arno wrote:
>> I see that Ian has marked the proposed routing args
>> convention as accepted. I have updated selector and
>> now consider it a stable feature so feel free to use it.
>>
>> http://wsgi.org/wsgi/Specifications/routing_args
>> https://lukearno.com/projects/selector/
>>
> 
> Hello there,
> 
> Sorry for being so late into the discussion. I must say I like that
> proposal and I completely sedond it. Except for one small point, the
> spec says:
> 
> "The values in routing_args need not be strings (except for the keys of
> named_args). For instance, a dispatcher is allowed to parse
> /archive/2005/10/01 into ((), {'date': datetime.date(2005, 10, 1)})."
> 
> This could be an issue for deployment if we consider that applications
> or other middleware will not be able to know what a middleware that
> implements this proposal has decided to do, map the values or not.
> 
> Say I have the value '00001' in my URI, I don't want the dispatcher to
> assume it's an int and maps it to '1'. Maybe this value is an identifier
> for me and I need the complete value. There is a loss of information.

My assumption was that, while non-strings are allowed, it would be 
something the dispatcher would handle when asked to do so explicitly. 
That is, a dispatcher shouldn't speculatively coerce values to integers 
or dates.  Every dispatcher has some kind of setup/configure routine, 
which is where type coercions are likely to go.

If this doesn't seem clear from the spec, this could be noted.

-- 
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Reply via email to