@paul.j3, thanks for the sample code for argparse extension. I agree that subclassing is a way to go for use in third-party projects. But, if someone ever wanted to add an abstraction layer in front of argparse.ArgumentParser and configparser.ConfigParser in the standard library, then modification of the argparse module might be more convenient.

However, in the intervening months since I originally filed this ticket, I ended up exploring an alternative to inspecting populated argparse.ArgumentParser instances for this use case (parser abstraction layer). The module I ended up writing is more of a framework in that it lets you supply argument and config parsers and then populate them via a common interface. While this design is perhaps higher maintenance, I think that it gives more flexibility and control than inspecting already-populated parsers. So, from my perspective, I no longer consider this use case to be a compelling reason for adding more optparse-like behavior to argparse.

(If there interest in the little framework that I wrote, I can share my code and take the discussion to an appropriate mailing list.)

Again, thanks for taking the time to write the argparse_extended.py code.