The following code, when run with "--help", omits the trailing newlines from the epilog.  It should just emit the string verbatim.  If the developer didn't want the extra newlines, he/she wouldn't have put them there.


import argparse
parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter,
                                 epilog="foo\n\n")
parser.parse_args()

Can we have this followed up please.

I suspect fixing this isn't going to be easy.

Extra lines are removed by the top most `formatter` function: 

    def format_help(self):
        help = self._root_section.format_help()
        if help:
            help = self._long_break_matcher.sub('\n\n', help)
            help = help.strip('\n') + '\n'
        return help

RawDescriptionHelpFormatter on the other hand just changes one deeply embedded function:

    def _fill_text(self, text, width, indent):
        return ''.join(indent + line for line in text.splitlines(keepends=True))

That `format_help` function has no way of distinguishing between '\n' that were part of the raw text, and which were added while assembling the various parts.

It could be instructive to try this version of format_help and see just how many \n are being removed:

    def format_help(self):
        help = self._root_section.format_help()
        return help

A user could preserve blank lines by including a space (or more) in each.  That is, instead of ending with '\n', end with '\n \n'.

epilog = 'Epilog: No wrap text %(prog)s\n\tNext line\n \n'

---------------

I just checked a simple help.  The description and epilog get an extra blank line during assembly.  If 'epilog=None', there are 2 blank lines, which normally get reduced to one \n. 

So the philosophy of the formatter is to freely add \n between sections, regardless of whether they are empty (None) or not, and then deal with excess \n at the end.  Preserving blank lines during Raw requires rethinking that underlying philosophy.

Adding a space as Paul suggests works. I'll close this soon if nobody objects.

It's nice to see this is still being worked on after all these years :-)

I'm not actually convinced the proposed fix makes sense.  It swaps out one incorrect behavior for a different incorrect behavior.  If it really is more effort than it's worth to fix this (and given msg223371, I agree it probably is), then at least the original behavior makes more sense, as it's got years of history behind it and dropping an extra blank line is less arbitrary than adding an extra space.  

I've long since forgotten what real-world issue led me to open this, but it seems like it be easier to just document that extra trailing whitespace may not be honored.