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

[Laura Creighton]

In a message of Thu, 10 Sep 2009 18:11:21 EDT, Barry Warsaw writes:
>Then we have a serious long term problem.  Taken to its logical =20
>conclusion, we're going to end up with a batteries included standard =20
>library with nothing but old, /effectively/ obsolete APIs with all the =2
>0=
>
>good new stuff that people want in the Cheeseshop.  Okay, in reality =20
>it will always be a mix, but I do think this policy means that the =20
>APIs in the stdlib will degrade and ultimately decay over time.
>
>If that's the case, why even have a stdlib?

That is, actually, pretty much what I want a stdlib for.  I don't want
it to contain the newest, greatest, and best ways of doing things.  I
want it to contain the things that people are willing to maintain until
hell freezes over, which will largely be things that aren't ever going
to change until hell freezes over.

I want users to know that if they want the latest, greatest, and best
ways of doing things -- the way we recommend people do things now --
then they should not be assuming that the standard library has it.
The point of using things in the standard library is so that you
will have a reason to believe that if you write your code using
this stuff, then you don't have to worry (much, at any rate, there
is always Python 3.0) about having to change your code at some later
date because the standard library now has a new way of doing things
which some people like a lot better than the old way you used.

Right now there are a whole lot of users of python programs who have
no programming skills whatsoever.  Waking up one morning and discovering
that their computing environment has gone to hell because the default
Python is now 3.7 and now the option parsing in their programs don't
work any more -- and they will have to get a replacement from the
original author of the tool, or some other programmer seems a remarkably
uncivil way to treat your users.

If new python programmers cannot be trusted to read the standard library
manual and understand what a paragraph that says:

       XXX is included in the standard library for reasons of
       backwards compatibility.  We strongly recommend that you use YYY
       instead.

then they are too clueless to worry about.  But if, having read this,
they choose to use XXX anyway, as today many people use getopt instead
optparse, when they are writing python programs that will
only be deployed on windows and who want the /option syntax that optparse
denies them, well then, that's their choice too.

I don't know anything about argparse, but reading the docs leads me to
believe it is a big improvement on optparse, which I dislike.  But
Simon Willison's optfunc http://simonwillison.net/2009/May/28/optfunc/
looks interesting to me as well, as would a parser that took its information
from docstrings.

There are two foolish attitudes here.  The first is that being tidy, or
impossible for newbies to misunderstand, because we won't give them the
option of using the wrong stuff is a higher value than not breaking
perfectly good working code.  It's better to teach the newbies that
there are lots of options out there than to hide this fact from them.

The second foolish attitude is that nobody seems to be discussing
'do we like argparse enough to be willing to maintain it for the
indefinite future as part of the standard library'.  Because, to my
mind, that is the real question.  If we no longer care about that,
and things in the standard library can be removed 'whenever we have
a replacement that we like better', then the standard library is no
longer really a _standard_ library, but rather a _stuff we suggest
you use_ library.  And do we really want one of those?

I sure don't.

Laura


<snip>
>-Barry