On Tue, Sep 15, 2009 at 1:02 PM, Laura Creighton <l...@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 _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
