Some people prefer argparse, some people prefer decorator-based syntax (like django-boss or argh), there are people prefer other methods (e.g. docopt). I think it is better not to invent yet another command-line framework.
Maybe delegate option parsing to user favorive library and provide some basic utilities for management command registration and execution instead? I didn't think of API yet, but the idea is: - django code setups settings, validates models, activates proper translation, maybe manages transactions. - developer registers management command (so it works in e.g. ./manage.py help and call_command); implements some interface (e.g. 'run_from_argv' and 'help' methods); parse options in 'run_from_argv' and do whatever needed. воскресенье, 12 августа 2012 г., 16:32:49 UTC+6 пользователь Florian Apolloner написал: > > 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. > > Maybe usage of argparse might improve a few things to write complex > management commands (eg subparsers, > http://docs.python.org/dev/library/argparse.html#argparse.ArgumentParser.add_subparsers) > > -- although it's 2.7+ > > Cheers, > Florian > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/aAUIxq8u5E8J. 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.
