ion vs refcounting, etc). Same
idea for documentation.
The idea is to a) put CPython on a more equal footing with the other
implementations, and b) to remove the need to have
Jython/IronPython/PyPy-specific cases in the CPython standard library.
I believe there was a more formal explanation of the p
,list}?
- A poll of Guido?
- Grepping your company's source code?
- Grepping my company's source code?
- Number of questions about the module on python-list this month?
- Number of hits Google Analytics records for the module's
documentation this quarter?
Collin Winter
___
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
7;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.
Collin Winter
___
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
On Tue, Sep 15, 2009 at 3:49 PM, Antoine Pitrou wrote:
> Le mardi 15 septembre 2009 à 14:38 +0000, Collin Winter a écrit :
>> This is no
>> different than upgrading versions of Postgres, gcc or Linux: it has
>> risks, but gcc doesn't upgrade itself on its own.
>
On Tue, Sep 15, 2009 at 1:02 PM, Laura Creighton wrote:
> In a message of Tue, 15 Sep 2009 14:38:20 -0000, Collin Winter writes:
>
> of Python without going through some sort of migration process>
>
> This is what happens every time /usr/bin/env python changes.
I do not unders
