All commit authors signed the Contributor License Agreement.

All commit authors signed the Contributor License Agreement.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again.

Thanks for making the requested changes!

@savannahostrowski: please review the changes made to this pull request.

This PR is stale because it has been open for 30 days with no activity.

I've "resolved" issues I believe to be addressed in an effort to facilitate progress.

Thanks for the patience on this, and for picking it back up earlier this year.

After spending more time thinking about this, I don't think a fifth formatter class is the right addition. The direction I'd like to keep argparse in is "good enough for basic CLIs". There are a lot of richer CLI libraries on PyPI now, and growing argparse's surface area makes it harder to maintain and harder to evolve.

There's also a specific concern I have that this PR surfaces which is around composability. The existing four formatters don't compose, so a user who wants paragraphs and defaults still ends up needing to write a multi-inheritance subclass. Adding ParagraphHelpFormatter extends that pattern without solving the problem the user actually has, and once it's in the stdlib, it's part of the API forever, which constrains any future redesign aimed at fixing composability.

Meanwhile, argparse-formatter, which you maintain, already serves the users who need this today, and can iterate in ways the stdlib can't. Given that, I'm going to decline this and close the PR.

Meanwhile, argparse-formatter, which you maintain, already serves the users who need this today, and can iterate in ways the stdlib can't.

Adoption of argparse-formatter is significantly hindered by the reticence of some people to face the possible risk disclosed in the README:

Note that ParagraphHelpFormatter is implemented by overriding two private methods in the default argparse formatter, and that the internals of that class are not considered part of the argparse API. There is therefore a (vanishingly) small risk that the code may break with a future standard library release.

That is why I've been supporting this submission for 6 1/2 years.