On Sun, Aug 12, 2012 at 6:32 PM, Florian Apolloner <[email protected]> wrote: > Hi, > > > On Sunday, August 12, 2012 2:22:58 AM UTC+2, Russell Keith-Magee wrote: >> >> I'll agree that it looks appealing. However, as always, my question is >> about backwards compatibility. > > > Seriously? In my eyes it's ugly, especially if you have more than one > options. Eg imagine you have decorated a function with @argument 6 times. > Even though make_option isn't much better in that way I think that a class > looks nicer and is easier to skim over.
The part that is appealing to me is the reduction of boilerplate. In 99% of cases, a management command should be able to be defined with a single function. The simplest possible management command at the moment is a method in a class in a module in a module. That's a lot of boilerplate. The multiple @argument decorators don't particularly offend me personally, but I also don't think the exact syntax for the argument decorators is the important part of the proposal -- the important part is the @command decorator, and the 'single function' nature of the end product. If Zach's proposed @argument decorator doesn't appeal to you, I'm certainly open to discussion on other ways that the argument requirements of a command could be defined. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
