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

[Brett Cannon]

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.

This idea is not far off from what we already do. There were a bunch
of deprecated modules in the standard library I ripped out for Python
3 that had been slated for removal for ages. It's just nobody bothered
to remove them.

> On Thu, Sep 10, 2009 at 4:35 PM, Brett Cannon <brett at python.org> wrote:
>>
>> On Thu, Sep 10, 2009 at 15:18, Barry Warsaw <barry at python.org> wrote:
>> > On Sep 10, 2009, at 6:04 PM, Antoine Pitrou wrote:
>> >
>> >> The main reason, as I understand, is to make the big picture clearer
>> >> for
>> >> new users because there's only one advertised way to do it. While it is
>> >> very nice for a clean sheet approach, it certainly isn't a consolation
>> >> for people who will have to rewrite their recently broken code...
>> >
>> > Perhaps this indicates a solution then.  Let's leave getopt and optparse
>> > in
>> > the stdlib as long as they aren't totally bitrotted into
>> > non-functionality,
>> > or as long as there is someone willing to maintain them as the language
>> > evolves.  But let's effectively deprecate them by moving their
>> > documentation
>> > to the backwaters so the average Python programmer will not find them,
>> > but
>> > will find argparse instead.  Once argparse is in the stdlib, all new
>> > code
>> > should use be using it exclusively.
>> >
>>
>> As long as they always raise a deprecation warning and it is clear
>> they are no longer maintained then fine. Modules could be in stages
>> of:
>>
>> 1. pending deprecation
>> 2. deprecation
>> 3. perpetual, unmaintained bitrot (w/ docs removed; deprecation can
>> point to last version w/ docs)
>> 4. deletion when we think no one is using it anymore (maybe next major
>> revision of Python)
>>
>> And this should only apply to pure Python code as I don't want build
>> dependency issues lying around forever. If we can make sure that the
>> Cheeseshop gets its version updated after every micro release while it
>> is in stage 1 or 2 this could actually work.
>>
>> -Brett
>> _______________________________________________
>> stdlib-sig mailing list
>> stdlib-sig at python.org
>> http://mail.python.org/mailman/listinfo/stdlib-sig
>
>
>
> --
> Jim Baker
> jbaker at zyasoft.com
>