[stdlib-sig] should we try to add argparse?
Jim Baker
jbaker at zyasoft.com
Fri Sep 11 00:40:17 CEST 2009
+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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20090910/c5916530/attachment-0001.htm>
More information about the stdlib-sig
mailing list