Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Bugs

[issue6247] should we include argparse

 

 

Python bugs RSS feed   Index | Next | Previous | View Threaded


report at bugs

Dec 7, 2009, 12:32 PM

Post #1 of 2 (162 views)
Permalink
[issue6247] should we include argparse

anatoly techtonik <techtonik [at] gmail> added the comment:

Argparse seems to be overloaded with rarely used features. Instead of providing
API to add these features and allow users copy examples it tends to be an all-in-
one solution that is hard to use due to abundance of specific parameters.

Look at constructor, for example -
http://argparse.googlecode.com/svn/tags/r101/doc/ArgumentParser.html#usage
{{{
description - Text to display before the argument help.
epilog - Text to display after the argument help.
version - A version number used to add a -v/–version option to the parser.
add_help - Add a -h/–help option to the parser. (default: True)
argument_default - Set the global default value for arguments. (default: None)
parents - A list of :class:ArgumentParser objects whose arguments should also be
included.
prefix_chars - The set of characters that prefix optional arguments. (default: ‘-
‘)
fromfile_prefix_chars - The set of characters that prefix files from which
additional arguments should be read. (default: None)
formatter_class - A class for customizing the help output.
conflict_handler - Usually unnecessary, defines strategy for resolving conflicting
optionals.
prog - Usually unnecessary, the name of the program (default: sys.argv[0])
usage - Usually unnecessary, the string describing the program usage (default:
generated)
}}}

the only useful arguments by default is 'description' and 'add_help' (which is
better to see as 'no_help' to turn off default behaviour). 'version' is not
useful, because it adds '-v' shorthand that is often used for verbosity.
'prefix_chars' is not useful, because the only sense one may need it is to provide
windows conventions like '/longarg' for '--longarg' and not '//longarg', but it
doesn't allow to do so.

Everything else is constructor bloat, and even with such abundance of options it
still unable to generate usage help prefixed by program name and version - the
sole feature I miss from optparse.

-1 for now

----------
nosy: +techtonik

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6247>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Dec 7, 2009, 12:59 PM

Post #2 of 2 (142 views)
Permalink
[issue6247] should we include argparse [In reply to]

Steven Bethard <steven.bethard [at] gmail> added the comment:

@techtonik: If you have a specific feature request for argparse, I
recommend that you file an issue on the argparse tracker[1]. I assure
you that despite the fact that you only have need for a couple of the
constructor parameters, the rest exist because people have asked for
them. Fortunately, since they're keyword parameters, you only have to
specify the ones that you care about.

[1]http://code.google.com/p/argparse/issues/list

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue6247>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Python bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.