What steps will reproduce the problem?
1. Run 'python subcommands.py -h' (attached file)
2. Check the ordering of the subcommands in the output:
----
subcommands:
  {a,c,b,e,d}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help
----

The ordering between brackets is different than the ordering in the one-line help for each command below. This could be a little confusing to the user.


What is the expected output? What do you see instead?
The expected output would be to use the same ordering in both places. In particular the same ordering that was used in the code when using the _SubParsersAction.add_parser method:
----
subcommands:
  {a,b,c,d,e}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help
----


What version of the product are you using? On what operating system?
OS: Ubuntu
Version: source code (rev. 87)
Python: 2.6.5

Please provide any additional information below.
Please have a look at the attached diff. It contains a patch that worked for me to preserve the ordering used in the code.

To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary).

It contains a patch that worked for me to preserve the ordering used in the code.

To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary).

It would be simpler to use an OrderedDict.

While the ordered dict is a nice option, the one-line patch that is attached to the report works in python < 2.7 without adding any external dependency.

In my opininion, that's interesting for those using argparse with earlier versions of python.

Sorry, "simpler" was the wrong choice of word :)

Anyway, it's up to Steven.

Thanks for the nice report and patch! I don’t know if Steven maintains argparse first in Python’s repository and then makes external releases or if he touches first his argparse repo and then Python’s, but if it’s the former, please generate your diff again from the top directory of the checkout (see http://www.python.org/dev/patches/).

Could you add tests too?

Yes, please generate patches from the Python repository.

Thanks!

Guidelines: http://www.python.org/dev/patches/

Working on it.

Finally I had to use an OrderedDict as suggested by R. David Murray because it wasn't safe to rely on _choices_actions in HelpFormatter class (i.e. previous patch wasn't valid):
- _choices_actions attribute is only present in _SubParsersAction class
- Even if action object is an instance of _SubParsersAction, _choices_actions only contains data for for subparsers that contain a help description.

Regarding the test cases:
- TestHelpSubparsersOrdering and TestHelpSubparsersWithHelpOrdering have been added
- TestHelpFormattingMetaClass has been modified:
  - New subparsers_signatures tester attribute added to test subparsers help.
  - If a 'signatures attribute' isn't present in tester object, then isn't consumed
  - assertMultilineEqual used instead of assertEqual to make it easier to debug test case failures.

Despite trunk.diff can be successfully applied to py3k branch, please find attached the patch generated from py3k branch.

Just for the record, please find attached an uglier patch for python < 2.7 that doesn't have the same problems as the first one I uploaded and passes all the test cases (tested with python 2.6).

In py3k.diff, the changes to argparse and new test cases look good to me. I don’t know why you’ve added hasattr tests in test_argparse.py.

The hasattr expressions were added to TestHelpFormattingMetaclass because:
- A new attribute (subparsers_signature) was added in test classes that wasn't used in the past.
- The new test classes didn't make use of some of the already in place attributes (argument_signatures, argument_signatures)
- The old test classes didn't make use of the new attribute (subparsers_signature).
- TestHelpFormattingMetaclass assumed that those attributes were present in test classes (otherwise an exception was raised).

Hence, in order not to change/break a lot of test cases, I decided to add the hasattr expressions.

New changeset 74f9ed48ae5d by Steven Bethard in branch '3.2':
Issue #9026: Fix order of argparse sub-commands in help messages.
http://hg.python.org/cpython/rev/74f9ed48ae5d

New changeset de29472c6a84 by Steven Bethard in branch 'default':
Issue #9026: Fix order of argparse sub-commands in help messages. (Merged from 3.2.)
http://hg.python.org/cpython/rev/de29472c6a84

New changeset 75ec20b4c50e by Steven Bethard in branch '2.7':
Issue #9026: Fix order of argparse sub-commands in help messages. (Merged from 3.2.)
http://hg.python.org/cpython/rev/75ec20b4c50e

Sorry for letting this bug sit around for so long. I committed a slight variant of your patch to 2.7, 3.2 and 3.3. Thanks!

This problem is occurring again in python 2.7.7, can we open it again?

@ddvento: This issue has been closed and the fixes for it released several years ago.  Comments added here will likely be ignored.  If you believe there is a problem with current releases (for Python 2, Python 2.7.9 is current), please open a new issue and document how to reproduce, including on what platform(s) and with which versions of Python.  FWIW, the original test case in this issue works correctly with both a 2.7.6 and current 2.7.9 on the platforms I tried it with.

You are right, this problem is not coming from python itself, but more from
setuptools and its use by scoop. See
https://github.com/soravux/scoop/issues/16 and
http://stackoverflow.com/questions/29374044/ for details

Regards,
Davide Del Vento,
NCAR Computational & Information Services Laboratory
Consulting Services Software Engineer
http://www2.cisl.ucar.edu/uss/csg/
SEA Chair http://sea.ucar.edu/
office: Mesa Lab, Room 55G
phone:  (303) 497-1233

On Thu, Apr 2, 2015 at 1:45 AM, Ned Deily <report@bugs.python.org> wrote:

>
> Ned Deily added the comment:
>
> @ddvento: This issue has been closed and the fixes for it released several
> years ago.  Comments added here will likely be ignored.  If you believe
> there is a problem with current releases (for Python 2, Python 2.7.9 is
> current), please open a new issue and document how to reproduce, including
> on what platform(s) and with which versions of Python.  FWIW, the original
> test case in this issue works correctly with both a 2.7.6 and current 2.7.9
> on the platforms I tried it with.
>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue9026>
> _______________________________________
>