[stdlib-sig] should we try to add argparse?
brett at python.org
Fri Sep 11 01:06:52 CEST 2009
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
> 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.
More information about the stdlib-sig