[issue9253] argparse: optional subparsers
Changes by BJ Dierkes wdier...@gmail.com: -- nosy: +derks ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23487] argparse: add_subparsers 'action' broken
New submission from BJ Dierkes:
Related: http://bugs.python.org/issue9253
I came across issue9253 in trying to implement a default action for a subparser
namespace. In the absence of a 'default' option, I thought that it may be
possible by adding an 'action' to 'add_subparsers'. Per the documentation this
should be possible:
https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers
[QUOTE]
action - the basic type of action to be taken when this argument is
encountered at the command line
[/QUOTE]
That said, custom actions on 'add_subparsers' doesn't appear to work at all:
import argparse
class CustomAction(argparse.Action):
def __call__(self, parser, namespace, values, option_string=None):
print('Inside CustomAction')
setattr(namespace, self.dest, values)
root_parser = argparse.ArgumentParser(prog='myapp')
sub_parser = root_parser.add_subparsers(dest='commands',
action=CustomAction)
args = root_parser.parse_args()
Produces:
$ python argtest.py --help
Traceback (most recent call last):
File argtest.py, line 46, in module
sub_parser = root_parser.add_subparsers(dest='commands',
action=CustomAction)
File
/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/argparse.py,
line 1661, in add_subparsers
action = parsers_class(option_strings=[], **kwargs)
TypeError: __init__() got an unexpected keyword argument 'prog'
Erroneous documentation maybe? Tested the same on Python 2.7 and 3.3.
--
components: Library (Lib)
messages: 236254
nosy: derks
priority: normal
severity: normal
status: open
title: argparse: add_subparsers 'action' broken
type: behavior
versions: Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23487
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22848] Subparser help does not respect SUPPRESS argument
BJ Dierkes added the comment:
I would like to add to this regarding the following:
[QUOTE]
Why would a user want to use `help=argparse.SUPPRESS`, as opposed to simply
omitting the `help` parameter? The effect would be the same as your patch.
[/QUOTE]
This actually isn't the case, if you omit the 'help' option entirely, the
sub-parser is still listed in the {short_list}. For example:
import argparse
root_parser = argparse.ArgumentParser(prog='myapp')
root_parser.add_argument('--foo', action=CustomAction)
sub_parsers = root_parser.add_subparsers(dest='commands',
title='subcommands')
sub_parser = sub_parsers.add_parser('sub-command-1', help='useless help
txt')
sub_parser = sub_parsers.add_parser('sub-command-2', help=argparse.SUPPRESS)
sub_parser = sub_parsers.add_parser('sub-command-3')
args = root_parser.parse_args()
You end up with:
$ python argtest.py --help
usage: myapp [-h] [--foo FOO] {sub-command-1,sub-command-2,sub-command-3} ...
optional arguments:
-h, --helpshow this help message and exit
--foo FOO
subcommands:
{sub-command-1,sub-command-2,sub-command-3}
sub-command-1 useless help txt
sub-command-2 ==SUPPRESS==
The 'sub-command-3' is still listed in the {sub-parsers} where, if I want
to hide a sub-parser... I don't want to see it anywhere. Would be ideal to
have a 'hide=True' option for sub-parsers and arguments alike. All the same
functionality, you just wouldn't see it in '--help'.
--
nosy: +derks
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22848
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12686] argparse - add 'hide' feature
New submission from BJ Dierkes wdier...@gmail.com:
Having the ability to 'hide' positional/option arguments and subparsers in
argparse would be useful. For example, I might want to add a subparser for
'somecommand-help' which would be a commands specifically for displaying help
output of 'somecommand'. There is no reason I'd want to display this as an
available argument... but rather simply add to the description For more info
try command-help.
Something like:
parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
somecommand_help = sub.add_parser('somecommand-help', hide=True)
OR
parser.add_argument('--some-crazy-option', hide=True).
It would then not display in the '--help' output, but would still function when
'somecommand-help' or '--some-crazy-option' is passed at command line. Would
also be an extra bonus to add some sort of interface to
'list_hidden_arguments').
--
components: None
messages: 141601
nosy: derks
priority: normal
severity: normal
status: open
title: argparse - add 'hide' feature
type: feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12686
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Database Abstraction Layer And/Or ORM
Hello all, I am looking for opinions on preferred methods of Database Abstraction Layer or Object Relation Mapper (I'm using Python 2.5). I have found a number of options such as those listed here: http://wiki.python.org/moin/HigherLevelDatabaseProgramming I'm not looking for a holy war based on whether a DAL/ORM *should* be used, and/or if it is preferred over direct access to the database API layer. I understand that can be a lengthy discussion. I would just like to see if there is a common 'preferred choice' in the area. I am coding an application around SQLite, but need to keep the flexibility to allow the use of MySQL (or other). Thoughts? -- http://mail.python.org/mailman/listinfo/python-list
