Okay, so I've looked at the previous discussion on this topic, and the code. Firstly let me say a big thank you to everyone who has worked on Django, it's a fabulously useful piece of software, and a lot of fun to work with.
By my lights, changeset 8760 could be considered to induce a regression. I say this because if you look at the doctests on lines 87-92, it seems pretty clear that original author had args and kwargs playing together happily. Whether or not anyone other than this Killarny fellow, and myself give a rat's patoot is another story :D . It seems like the behavior around args & kwargs isn't just unsupported in url reversal, but is also not supported very well in forward url matching. Aside from having had to debug into django a little bit and note that it was dropping my args on the floor because I had kwargs, and then having to change a bunch of automatically generated urls this hasn't given me much grief. I do feel that the docs talking about urlconfs could use a more direct approach. I'd add the following very forthright disclaimer to http://docs.djangoproject.com/en/dev/topics/http/urls/#topics-http-urls : Django UrlConfs look a great deal like Python Regular Expressions from the re module, but they are *not*. For reasons of development expediency and runtime efficiency, only a subset of the functionality from the re module is supported. Including both unnamed groups and named groups will result in the values of the unnamed groups being matched against, but not passed through to the view function. Use of | is not supported at all. I'd add that to the Overview section right between the two extant paragraphs. In terms of adding back args and kwargs playing together nicely in the Garden of UrlDen, it would seem to me to be accomplishable by doing the following(I'm referencing Django 1.1 line numbers here, if there's interest in a patch I will work one up against SVN): 1) In django.core.urlresolversRegexURLPattern.resolve kwargs = match.groupdict() args = match.group if kwargs: for value in kwargs.values: remove a single copy of the value from the list args 2) In django.core.urlresolvers.RegexURLResolver._populate: Make necessary changes to populate self._reverse_dict with values of the form ("url_template", argParams, kwargParams) where it is currently populated with values of the form ("url_template", params) 3) In django.core.urlresolvers.RegexURLResolver.reverse: Remove exception throw if both args and kwargs are present: use substring to remove groups indexed by kwargs in template string. this can be optimized for repeated runs by making a data structure that either precomputes the substring indices or memoizes them such a structure would only increase the space complexity of the url module by a constant factor discard candidates that have different numbers of non-keyword args than we are presented with discard candidates that have group patterns that don't match our unnamed groups for remaining candidates get back their original template string discard candidates that don't have the right named groups discard candidates whose named group regex's don't match our named group parameters if we have a candidate then we are good, otherwise there is no reverse url match If the community is interested in regaining the capacity to have args and kwargs in the same urlpattern I'd be happy to work up a patch following those outlines and run it through whatever tests are desired. Cheers, Alex On Sep 7, 2:59 pm, vegas <alexander.fair...@gmail.com> wrote: > Thanks for the pointer to previous discussion, will review and see if > I can contribute something useful. > > Cheers, > > Alex > On Sep 6, 12:58 am, Karen Tracey <kmtra...@gmail.com> wrote: > > > On Sun, Sep 6, 2009 at 12:16 AM, vegas <alexander.fair...@gmail.com> wrote: > > > > Hi guys, > > > > I was just doing some work, and I noticed that passing args and kwargs > > > to reverse raises an exception which explicitly tells me not to do > > > that: > > > if args and kwargs: > > > raise ValueError("Don't mix *args and **kwargs in call to > > > reverse()!") > > > I don't see an obvious reason for this to be the case, and looking at > > > the end of the method, if search fails then a NoReverseMatch exception > > > is raised with error text that leads me to believe that either at one > > > point args and kwargs were mixable, or people would like them to be. > > > > I'm a far cry from a django developer, but I could probably rustle up > > > a patch to make args and kwargs acceptable for reverse toward the end > > > of next week if someone hasn't already done this and it's considered > > > desirable. > > > Are you sure it is as easy as you think? This has been requested: > > >http://code.djangoproject.com/ticket/8764 > > > and discussed: > > >http://groups.google.com/group/django-developers/browse_thread/thread... > > > before. I don't get the idea it is that easy to do efficiently and without > > confusing-for-users limitations on when mixing will and will not work. > > > Karen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
