At 05:42 PM 10/31/2006 -0600, Ian Bicking wrote:
Phillip J. Eby wrote:
At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
Anyway, I've updated the spec:
http://wsgi.org/wsgi/Specifications/url_vars
http://wsgi.org/wsgi/Specifications/url_vars?action=diff
Is everyone happy with this version?
I
Ian Bicking wrote:
One little question: if a dispatcher can never produce
one of the kinds of information (which happens for some
of them), should they put in an empty list/tuple or
empty dict, or should they put in None for that item?
I'm currently saying they must put in a list/tuple or
Robert Brewer wrote:
Ian Bicking wrote:
One little question: if a dispatcher can never produce
one of the kinds of information (which happens for some
of them), should they put in an empty list/tuple or
empty dict, or should they put in None for that item?
I'm currently saying they must put
On Nov 1, 2006, at 9:33 AM, Phillip J. Eby wrote:
Yep, that was my reasoning; I think its most valuable use is as
arguments
to a callable, such that a dispatcher or routing system would just
invoke a
callable with some framework-defined arguments, combined with the *
and **
from the
Phillip J. Eby wrote:
At 05:39 PM 10/23/2006 -0500, Ian Bicking wrote:
By using a tuple or list, you can be sure you don't have a sparse list,
which probably isn't something any system is likely to handle. The
double underscores kind of mark __args__ as a special kind of key, so
it's less
Ian Bicking wrote:
Having thought about it, I think storing a tuple of
(args, kwargs) is the best way to do this, since it's
most explicit. Consumers can deal with args specially,
ignore them, or raise an error, as they see fit --
there are reasons to do each of these. Hiding args
in
At 04:17 PM 10/31/2006 -0600, Ian Bicking wrote:
One little question: if a dispatcher can never produce one of the kinds of
information (which happens for some of them), should they put in an empty
list/tuple or empty dict, or should they put in None for that item? I'm
currently saying they
Robert Brewer wrote:
Ian Bicking wrote:
Having thought about it, I think storing a tuple of
(args, kwargs) is the best way to do this, since it's
most explicit. Consumers can deal with args specially,
ignore them, or raise an error, as they see fit --
there are reasons to do each of these.
I feel even more +1 on ['wsgi.url_vars'] now. I implemented
as currently discussed in selector and it works out very well.
Selector now supports positional args in path expressions.
I even made some experimental little decorators so that
url_vars can go into method signatures. I don't know that
I
At 05:39 PM 10/23/2006 -0500, Ian Bicking wrote:
By using a tuple or list, you can be sure you don't have a sparse list,
which probably isn't something any system is likely to handle. The
double underscores kind of mark __args__ as a special kind of key, so
it's less likely to overlap with a
Simon Willison wrote:
I've spotted a potential problem with your wsgi.url_vars specification
suggestion.
http://wsgi.org/wsgi/Specifications/url_vars
The spec calls for wsgi.url_vars to refer to a dictionary. In Django, we
originally required named captures in regular expressions - but
11 matches
Mail list logo
