[Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
Guido van Rossum
guido at python.org
Tue Mar 13 15:52:17 CET 2012
On Mon, Mar 12, 2012 at 10:10 PM, Senthil Kumaran <senthil at uthcode.com> wrote:
> On Mon, Mar 12, 2012 at 07:23:11PM -0700, Andrey Petrov wrote:
>> I've had the pleasure of speaking with Guido at PyCon and it became evident
>> that some of Python's included batteries are significantly lagging behind the
>> rapidly-evolving defacto standards of the community specifically in cases like
>> urllib and urllib2, which lack important features provided by alternatives like
>> httplib2, requests, and my own urllib3.
> Well, I think I have address this because I am the maintainer of those
> modules in standard lib.
> First things first, it looks to me that trashing something gives good
> motivation to you (and others working on related modules). I don't
> have a problem with that.
> But on the other hand, if you think things can be improved in stdlib,
> you are welcome to contribute. Just remember that new features,
> refactoring with backwards compatibility, 'cool api' for new features
> should go in 3.3+ onwards. Bug fixes, confusions on what's RFC
> supported vs what's defacto standards, fine line between bugs and
> features, those can be considered for 2.7.
> I am personally in favor of constantly improving the standard library
> modules along with mention of any good libraries which can be useful
> for the purposes of the user.
> We already have lots of such references in standard library
> documentation. If there is a well maintained package, as long as the
> external package is active and maintained, we can have it as link in
> the docs. Sometimes those external packages become inactive too, in
> those cases, those should pruned. Its' all about maintaining libraries
> and docs and being helpful.
Well said. Improving existing stdlib modules is always welcome of
course! (And the bar is much lower than for adding new modules.)
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev