On Fri, Apr 1, 2016 at 11:32 PM, Shai Berger <s...@platonix.com> wrote:
> Hi,
>
> Finally found the time to go through this discussion.
>
> The first note that comes to mind is:
>
> Although it has already been pointed out more than once that positional
> arguments cannot follow keyword arguments, you both (Andrew and Vincent)
> keep
> giving examples such as
>
> # SYNTAX ERROR
> route('sms.receive', sender=r'\+44(?P<local_number>[0-9]+)$',
> Consumer)
>
> I believe the reason for that is the clash between the will to preserve the
> current `route(channel, consumer)` syntax, which is like the parallel
> `url(path_regex, view, **kw)` syntax, on one hand; and the instinct that
> the
> identifying parameters should be together, on the other hand.
>
> I think that the latter consideration prevails; unlike the kw parameters in
> url(), which are essentially parameters to the view, the kw parameters
> proposed for channel help select the consumer; and so they must be
> adjacent to
> the channel name -- and hence, the consumer must be the first argument.
>
Ah, that's an interesting ordering I hadn't considered before - the problem
is, I would have it (channel, kwargs, consumer) if I could, as generally
when I'm reading the file I want to identify things by route. For that
reason, I still like having the channel at the beginning as it makes it
obvious what the rest of the line is dealing with (websocket? http? etc.)
>
> A second thought is about multiple keyword arguments:
>
> It isn't clear if more than one keyword argument is allowed, and if so,
> what
> should be the semantics of the combination. When thinking about routing,
> it is
> almost obvious that if there are many kw arguments, they must all match for
> the whole route to match. But when thinking about includes, a different
> consideration arises: How do I specify routing in an app which deals with
> several incompatible channels?
>
> For argument's sake, let's say I have an app which can handle SMS's, mails
> and
> websocket.connect's. I want it to handle all of these if they come from
> within
> my company -- so, based on partial phone number, sender domain and client
> IP
> addresses, respectively. Would I need to have the app's routing.py module
> include()'ed three times? Or would it make more sense to give include() kw
> parameters an "or" semantics -- that is, match as soon as one argument
> matches?
>
The way I've done this in the chat example is two includes:
https://github.com/andrewgodwin/channels-examples/blob/master/multichat/multichat/routing.py
https://github.com/andrewgodwin/channels-examples/blob/master/multichat/chat/routing.py
>
> I think both of these solutions are bad, and the only solution that makes
> sense is to allow a more complex structure of argument -- so that multiple
> kw
> args are all required to match, and for a disjunction of channels we use
> positional channel-spec args -- something like,
>
> include('my_app.routing',
> chan_spec('sms.receive', sender=r'\1212555(?:[0-9]{4})$'),
> chan_spec('mail.receive', sender=r'^(?:\W+)@my_org.com$),
> chan_spec('websocket.connect', remote_ip='^172.10'),
> )
>
> where a set of kw parameters are considered to all belong to one implicit
> chan_spec.
>
>
I'm not entirely convinced this is better than just having three includes;
it would be basically the same number of lines, and would work just as you
suggest, with the added benefit of no extra thing to import.
Is there something about this method you think is better than three
includes? Remember, routing specifies the variable inside the module
(unlike url includes, which only specify the module) so you can still keep
the three routing sets in the one routing.py inside the app.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFwN1uoZLb7vonqO80QyxhF2wmsaQQO4rjjLsHi1nRUup1ZMVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
