[issue22848] Subparser help does not respect SUPPRESS argument

2015-04-15 Thread Matt Long

Matt Long added the comment:

I prefer the idea of help=SUPPRESSED resulting in a hidden subcommand. That 
is, one that does not show up at all in the usage/help output:

import argparse

parser = argparse.ArgumentParser(prog='myapp')
parser.add_argument('--foo', action=CustomAction)
sub_parsers = parser.add_subparsers(dest='commands', title='subcommands')
sub_parser = sub_parsers.add_parser('sub-command-1', help='sub-command-1 
help')
sub_parser = sub_parsers.add_parser('sub-command-2', help=argparse.SUPPRESS)
sub_parser = sub_parsers.add_parser('sub-command-3')

parser.parse_args(['-h'])

Would result in:

usage: myapp [-h] [--foo FOO] {sub-command-1,sub-command-3} ...

optional arguments:
  -h, --helpshow this help message and exit
  --foo FOO

subcommands:
  {sub-command-1,sub-command-3}
sub-command-1   normal subcommand help


Assuming this behavior, what should happen if you request help for a subparser 
with help=SUPPRESSED? That is, you know the subcommand exists even though it's 
not mentioned in the usage. I would assume it would show usage as normal (note 
the description kwarg for sub-command-2):

import argparse

parser = argparse.ArgumentParser(prog='myapp')
parser.add_argument('--foo', action='store_true')
sub_parsers = parser.add_subparsers(dest='commands', title='subcommands')
sub_parser = sub_parsers.add_parser('sub-command-1', help='sub-command-1 
help')
sub_parser = sub_parsers.add_parser('sub-command-2',
help=argparse.SUPPRESS,
description='description of suppressed 
sub-command-2')
sub_parser = sub_parsers.add_parser('sub-command-3')

parser.parse_args(['sub-command-2', '-h'])

Would result in:

usage: myapp sub-command-2 [-h]

description of suppressed sub-command-2

optional arguments:
  -h, --help  show this help message and exit


An edge case to consider: what should top-level help look like if ALL 
subparsers are suppressed? It seems like a degenerate scenario, but complete is 
important, right? The one that feels most correct to me is to follow the 
current behavior when you call add_subparsers but never call add_parser:

import argparse

parser = argparse.ArgumentParser(prog='myapp')
parser.add_argument('--foo', action='store_true')
sub_parsers = parser.add_subparsers(dest='commands', title='subcommands')
parser.parse_args(['-h'])

Currently results in:
usage: myapp [-h] [--foo] {} ...

optional arguments:
  -h, --help  show this help message and exit
  --foo

subcommands:
  {}

Another possibility would be to follow the current behavior when you never even 
call add_subparsers which would of course remove all notion that subcommands 
are accepted, but that doesn't feel right to me.

--
nosy: +mattlong

___
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



[issue22848] Subparser help does not respect SUPPRESS argument

2015-04-15 Thread Matt Long

Matt Long added the comment:

Here's a patch for the proposal in my previous comment.

As Barry mentioned, it wasn't as straightforward as I had hoped due to parts of 
the usage text being generated by the state of both self._name_parser_map and 
self._choices_actions.

--
Added file: http://bugs.python.org/file39040/issue22484.patch

___
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



[issue13549] Incorrect nested list comprehension documentation

2011-12-07 Thread Matt Long

New submission from Matt Long m...@crocodoc.com:

The description of nesting list comprehensions in section 5.1.5 of the main 
Python tutorial 
(http://docs.python.org/tutorial/datastructures.html#nested-list-comprehensions)
 is misleading at best and arguably incorrect. Where it says To avoid 
apprehension when nesting list comprehensions, read from right to left. This 
is incorrect and conflicts directly with the comment at the bottom of PEP 202 
(http://www.python.org/dev/peps/pep-0202/), which says the last index varies 
fastest.

Take the following example:

matrix = [[1,2],[3,4],[5,6]]
my_list = []
for row in matrix:
  for number in row
my_list.append(number)

The current documentation would suggest I do the following to achieve the same 
result with list comprehensions since the for statements should be read from 
right to left:

matrix = [[1,2],[3,4],[5,6]]
my_list = [number for number in row for row in matrix]

Running this code will result in an error. The correct form is:

matrix = [[1,2],[3,4],[5,6]]
[number for row in matrix for number in row]

Clearly the nesting order only matters when the inner loop depends on the outer 
loop as in my example above. There is no such dependency in the documentation's 
example, which is why it is does not result in an Error.

--
assignee: docs@python
components: Documentation
messages: 148994
nosy: docs@python, mattlong
priority: normal
severity: normal
status: open
title: Incorrect nested list comprehension documentation
type: behavior
versions: Python 2.6, Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13549
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com