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

[Brett Cannon]

On Thu, Sep 10, 2009 at 15:55, Collin Winter <collinw at gmail.com> wrote:
> On Thu, Sep 10, 2009 at 7:47 PM, Brett Cannon <brett at python.org> wrote:
>> On Thu, Sep 10, 2009 at 15:40, Jim Baker <jbaker at zyasoft.com> wrote:
>>> +1 - I don't want Python being like Java where the only deprecation that
>>> occurs is when code is actively harmful - and it still won't be removed for
>>> backwards compatibility's sake.
>>
>> The deprecation would be permanent, so it won't be like Java where we
>> support stuff only until we consider it harmful. And unlike Java we
>> would not keep the docs around forever, suggesting that you can just
>> simply ignore what the docs say. The modules would eventually
>> disappear from people's knowledge.
>
> If we allow the code to survive, eventually someone will need to
> maintain an application that uses the deprecated, now-docless module.
> If I were that person, I would curse the names of whoever left the
> code there but removed the docs and allowed bugs to creep in (if the
> module disappears from people's knowledge, it will likely disappear
> from our consciousness).
>

The docs would live on w/ the Python release that last contained it.
Plus the Cheeseshop release would have a copy of the docs.

I think PEP 4 (http://www.python.org/dev/peps/pep-0004/) needs to be
tightened up to flat-out explain what a deprecation means and how long
the code and docs will survive at minimum.

> Honest question, having only read the docs about argparse: would it be
> possible to merge the functionality of argparse into optparse and so
> preserve a greater measure of backwards compatibility? Some of the
> stuff I'm reading about in
> http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html
> looks like it should be able to be integrated fairly easily into the
> existing optparse structure.

Don't know. Would have to ask Steven about that. I wanted to first see
if people liked the idea of argparse enough.

-Brett