I hadn't intended to come off like an ingrate or be dismissive in my post, and I apologise for sounding that way; I was frustrated when I wrote it, which was a mistake. I have great respect for the development efforts for Django, and the polite comments in response to my post have only increased that respect.
In essence, I really wanted to see some justification for the choices made, which I was not able to find discussed anywhere else (even after searching on this list and on django-users) and I thank you, Malcolm, for taking the time to detail the thought processes. The examples from mrts are quite helpful for my particular situation, so thanks a bunch for that. I think I'll probably end up rewriting my views and decorators en-mass and making all of my args into keyword arguments, raising errors when required keywords are not present. My biggest remaining concern now is with the documentation. The section about reverse() does not mention this limitation, and perhaps it should. Additionally, the url template tag documentation seems to demonstrate the usage of mixed args and kwargs, and perhaps it shouldn't? http://docs.djangoproject.com/en/dev/topics/http/urls/#reverse http://docs.djangoproject.com/en/dev/ref/templates/builtins/#url Should I open a ticket for the documentation changes? On Wed, Jan 7, 2009 at 2:24 AM, mrts <m...@mrts.pri.ee> wrote: > > On Jan 7, 3:43 am, Malcolm Tredinnick <malc...@pointy-stick.com> > wrote: > > On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote: > > > 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. > > > > I'll disagree with this. Whilst it's easy when one is faced with a > > particular problem to imagine that it must be a common case, in reality > > there aren't really that many instances where mixing is required (in > > fact, I can't think of *any* where it could be compulsory -- it's purely > > an alternative representation, so rewrites are always possible). There > > are cases where it can be used, as you witness, but it's not *required*. > > E.g. Werkzeug Routes takes this further and handles *only* kwargs. > Less code, less complexity, less bugs, no problems whatsoever. > > It goes as follows (simplified look at request-resolve-response > cycle): > > def __call__(self, environ, start_response): > resolver = self.url_map.bind_to_environ(environ) > view, kwargs = resolver.match() > response = view(request, **kwargs) > return response(environ, start_response) > > +1 to current behaviour or dropping supporting positional args tuple > passing altogether to get rid of the complexity. > > Kilarny, which argument handling problems you have remain unsolved in > following examples? > > >>> def foo(a, b, c=None): # 2 required and 1 optional arg > ... pass > ... > >>> foo(**{'a' : 1, 'b' : 2}) > >>> foo(**{'a' : 1 }) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: foo() takes at least 2 non-keyword arguments (1 given) > >>> foo(**{'a' : 1, 'd' : 3 }) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: foo() got an unexpected keyword argument 'd' > > >>> def foo(a, b, **kwargs): # 2 required and any optional args > ... pass > ... > >>> foo(**{'a' : 1, 'b' : 1, 'd' : 3 }) > >>> foo(**{'a' : 1, 'd' : 3 }) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: foo() takes exactly 2 non-keyword arguments (1 given) > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
