The above ticket was opened a while back concerning the inability to define views that use both positional arguments and keyword arguments when expecting to use reverse() to match urls tied to those views.
I don't understand the rational here for not fixing this issue. The decision not to allow mixing args and kwargs seems like a lazy way to avoid coming up with a real solution. Forcing the use of one or the other but not both is simply not pythonic, and without some sort of discussion, seems silly. When a python framework does not allow valid python syntax to function properly, that sounds like a fundamental flaw in design to me. There are many instances where, in a complicated implementation of views, one might want to have a combination of required args and optional kwargs, and the inability to mix them introduces all sorts of complexities to the logic of the views that shouldn't have to be dealt with. Due to the abruptness with which I was referred to this list, I feel like I must be missing some obvious piece of logic in this decision, as many of the other tickets have well defined responses and rational for the decisions related to them, while this ticket has almost none. My personal stake in this issue has to do with one of my applications which relies heavily on a required argument on every view - an employee slug. I've built multiple decorators around this, and much of my functionality depends on that argument. On one of my views, I want to allow some filtering keywords to be optionally included on the view, and due to this bug I am simply unable to do that without (A) radically rewriting my application, or (B) writing two identical views which have different required arguments and defining a url for each. Option A is simply not feasible, and option B is just a silly thing to have to do, when if this bug were not an issue, I could simply use the syntax that any python method definition allows me to use. I imagine that an argument will be made that I should have developed my application from the start with this limitation in mind (which is what mtredinnick suggests in a comment on that ticket) but this limitation is not mentioned in the documentation anywhere that I could find, so I don't see how I could have known this until encountering it. And again, why would anyone expect this sort of a limitation, considering that it flies in the face of what python syntax allows everywhere else? Futher confusing the issue is the text at http://docs.djangoproject.com/en/dev/ref/templates/builtins/#url where apparently the url tag supports mixing args and kwargs just fine. I have not tested this yet, but the example given in the documentation there does exactly that: {% url path.to.some_view arg1,arg2,name1=value1 %} Is there an inconsistency between reverse() and {% url %}? I hope I have not come across badly in this post; I am trying to remain patient, but this is quite frustrating to come across such a perceived closed door regarding this bug. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
