[stdlib-sig] should we try to add argparse?

Steven Bethard steven.bethard at gmail.com
Sun Sep 13 19:52:23 CEST 2009


On Sun, Sep 13, 2009 at 12:31 AM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
> optparse's source code isn't cast in stone, therefore its interface can
> evolve.

While I agree with this comment in general, because optparse
officially exposes lots of internal details (OptionParser.largs,
OptionParser.rargs, Option.TYPE_CHECKER, Option.ALWAYS_TYPED_ACTIONS,
etc.) in practice it's extremely hard to evolve the optparse codebase
without introducing backwards compatibilities. If you don't believe
me, I recommend trying to implement argparse's support for
type=<callable> in optparse, while respecting Option.TYPES, etc. This
is one of the reasons in argparse I've been extremely conservative on
what constitutes the public API - I don't want the compatibility
nightmare that optparse has.

I guess one option would be to deprecate optparse's entire extension
mechanism and eventually replace it with argparse's, but I don't see
how that would really be any better than just including argparse
alongside optparse.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus


More information about the stdlib-sig mailing list