In argparse.py, I would put a utility function like `_prog_name` near the start in the 'Utility functions and classes' block.  

In test_argparse.py, I don't see the purpose of the `progname` changes in the TestParentParsers class.  That class wasn't producing an error, even though 'unittest' has a '__main__'.  Is there some other way of running the test that produces an error with the existing code?  

Most tests for 'usage' and 'help', use 'prog="PROG"' to get around the various ways that the tests can be run.  I don't see what TestParentParsers gains by not doing the same.  The 'prog' attribute has nothing to do with 'parents', at least not that I can tell.

I think a patch like this needs a new test(s), one that fails with existing  code, and run fine with the patch.  It also needs to work with almost any method of running the tests.  But writing such a test might be lot harder than writing the fix, since it involves system issues, and possibly mocking a package and a zip file.

Nick's suggestion regarding '__spec__' also needs to be considered.  It is an area of active development.  I'm not sure that 'argparse' should be getting into these details regarding how the script is invoked and/or packaged.

Finally, does this patch accomplish anything that the user can't do by directly setting the 'prog' attribute?  The user could even use a function like '_prog_name' to create that name on the fly.

'unittest.__main__' is an example of a package that gets around this '__main__' problem by redefining 'sys.argv[0]' before invoking the parser (optparse).  'Nose' also does this.