11874 - argparse assertion failure with brackets in metavars
ysj.ray
Seem as a problem in optparse.HelpFormatter._format_usage(): when the
generated usage string is too long(longer than 78, e.g.), python tries
to break the usage string into parts at some proper positions and group
them to multiple lines, then join the parts with space and assert it
equal with original usage string. The regular expression used to break
the usage string into parts is:
    """r'\(.*?\)+|\[.*?\]+|\S+'"""
So when there is '[]' in usage string, like in the example(there is '[]'
in metavar), the assertion fails.

metavar="[LIB,]FBNAME" seems quite reasonable and usable, in the case
that one want to define an option who has tow values and the first
is optional. So I suggest '[]' should be allowed in metavar, and the _
format_usage() needs fixed.

Here is a patch that fixes by changing the way breaking the usage string
to parts and remove joining the parts and assert it equal to original
usage string. Now the usage string is broken into intact each action of
group usage strings. I think this breaking granularity is enough.
Here's a patch that takes a different approach - rewrite _format_actions_
usage() so it formats groups (and unattached actions) directly.

It uses the same logic to determine when to format a group, but then it
calls _format_group_usage() to format the group, without the error prone
insert and cleanup business.  And by keeping a list of the parts, it
avoids the complications of parsing the text.  The only cleanup regex
removes () from single element groups.

In the nested get_lines function, I added 'line and' to

   if line and line_len + 1 + len(part) > text_width:

so it does not create a blank line before an extra long entry (e.g. 'c'*76).

I'm using the _format_group_usage() and _format_just_actions_usage()
in the Issue 10984 MultiGroupFormatter, just rearranging the logic in
its _format_actions_usage() method.  That patch could be rewritten to
depend on this one.

This patch also fixes http://bugs.python.org/issue18349, since the
metavar is never parsed.
Merge branch 'issue11874' into composite