Raymond Hettinger <raymond.hettinger@gmail.com> added the comment:

>> Sounds like another wet blanket argpment

> Please watch your tone.  It borders on being abusive.

I considered that as a canonical description of the type of negativity presented by your comment. It was not intended to be abusive, just a descriptive summary.


> It is entirely appropriate to set limits on the scope of what a module is trying to achieve.  It is appropriate to consider module learnability.  It is appropriate to limit sprawl and feature creep.  It is appropriate to consider whether the pattern being encouraged and supported by the PR is intellectually manageable by end users.


I agree that all those considerations are worthwhile, but I see this as a small extension that adds significant power. No one is forced to use the new features, or the old features, or argparse at all. There are already features in argparse that I simply ignore, because I have no need for them. It doesn't make using the feature I do use more difficult. I just look for what I need, and use those features.


> It is correct that argparse set out to handle more complex cases than optparse.  But even then, it was aiming to cases that commonly arose it the wild (subparsers are not uncommon).  It never aspired to be all things to all users.

And unfortunately, in so doing, it failed to support some cases that optparse could handle, although for the cases that argparse could handle, the user code to use it was far simpler.  This was improved somewhat by the addition of parse_intermixed_args.

Since argparse is provided in stdlib, it seems very reasonable to me to enhance it to support command line parsing paradigms used effectively since 1979, at least (ref: tar).