[stdlib-sig] Breaking out the stdlib

[Collin Winter]

On Tue, Sep 15, 2009 at 1:02 PM, Laura Creighton <lac at openend.se> wrote:
> In a message of Tue, 15 Sep 2009 14:38:20 -0000, Collin Winter writes:
>
> <stuff that indicates that  my users shouldn't be changing versions
> of Python without going through some sort of migration process>
>
> This is what happens every time /usr/bin/env python changes.

I do not understand. Why is "/usr/bin/env python" changing so
frequently on these systems? Why is it being changed without
consideration of the requirements of the software running on top of
it?

> final quote:
>
>>To speak more personally, and specifically to the issue of
>>getopt/optparse vs argparse: at Google, I'm part of the Python
>>readability team, which helps train the large numbers of Python
>>developers that the company produces. Part of this job involves
>>conducting detailed code reviews for new Python programmers,
>>explaining both Google style and idiomatic Python code generally,
>>suggesting library A over hand-written solution B. I am, frankly,
>>embarrassed whenever I have to explain the difference between getopt
>>and optparse, urllib and urllib2, popen2 vs os.popen* vs subprocess,
>>string.* vs str.*, etc. I cannot imagine how embarrassed I will be
>>when I have to explain why the standard library includes getopt,
>>optparse and argparse.
>
> You need to practice saying 'argparse is the preferred way to do
> things; getopt and optparse are maintained for compatibility reasons'
> until you can do this without embarassment.

I am embarrassed explaining why the core Python team, of which I am a
member, would consent to indefinitely maintain multiple, separate,
mutually-incompatible systems that all have the same purpose without
deprecating any of them. I do not understand why getopt was not
deprecated when optparse was introduced seven years ago; perhaps
someone can shed historical perspective on that decision. Pending that
elaboration, I do not understand why we would repeat that mistake
again with argparse now, or with some other module in the future.

> It also sounds to me as if you would be far less embarassed explaining
> to Google employees why they have to go off and rewrite all their old
> code which uses getopt than explaining to them why we have getopt,
> optparse, and argparse in the standard library.  I find this very odd.

I don't find "we found a better way" embarrassing. I don't find having
a single, unified, best-of-breed solution embarrassing. I don't find
having multiple years of advance notice to update your code
embarrassing (which is vastly longer than the deprecation windows we
have internally). I don't find consolidating developer time, energy
and attention embarrassing. I don't find progress embarrassing.

The commonly-expressed idea behind the stdlib is that it represents
best-of-breed code: it should have an independent userbase first, it
should have proven itself in the wild before it is allowed into the
stdlib. "Best" comes with baggage: it means that other solutions are
worse, and it admits the possibility that other code will someday
overtake the current solution to *become* best-of-breed. That was the
motivation then for including optparse: it was a more Pythonic way of
doing argument parsing, as opposed to getopt's faithful recreation of
C's limitations and restrictions. That is the motivation now for
including argparse: optparse is inflexible and doesn't support useful
functionality. We have to be open to the idea that we may have found a
new "best".

Collin Winter