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