Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Andrey Petrov-2]

Hi Pythonistas,

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.

Part 1:

I propose we add a snippet to the top of the documentation of specific archaic standard modules which encourages users to investigate third-party alternatives if they find the standard module frustrating or otherwise lacking. These notes would target new users, including those coming from other languages where the third-party library choices are not nearly as amazing as they are in Python.

(For what it's worth, Guido has verbally agreed to a proposal of this nature.)

What such a snippet might look like:

"Batteries are included with Python but sometimes they are old and leaky—this is one of those cases. Please have a look in PyPI for more modern alternatives provided by the Python community."

Additionally, I would like for us as a community to identify which other standard libraries (cgi? ssl? others?) are candidates for this kind of messaging in the official Python documentation.

Part 2:

I propose we add a new category of package identifiers such as "Topic :: Standard Library Alternative :: {stdlib_package_name}" which authors of libraries can tag themselves under. The documentation warning snippet will provide a link to the appropriate PyPI query to list packages claiming to be alternatives to the stdlib package in question.

Objections? Concerns? Improvements? What is the next step to making this happen?

Pythonically yours,

- Andrey (on behalf of Ori Livneh, Kenneth Reitz, Brandon Rhodes, David Wolever, and everyone else who contributed to this letter during our PyCon sprint.)

P.S. Appendix: Here are some additional snippet alternatives that were proposed:

> Batteries are included with Python but sometimes they are old and leaky—this is one of those cases. Please have a look in PyPI for more modern alternatives provided by the Python community.

> While this module has served Python programmers faithfully for many years, there are now many powerful alternatives available as third-party modules. To learn more about them, view the Python Package Index results for the category "Topic :: Standard Library Alternative :: asyncore." — [With the topic name as a hyperlink]

> This module has been identified by the community as crusty, a signal that better alternatives exist outside the standard library. Because the Python standard library is constained to maintain backward-compatibility, it does not always reflect what is current or common in the Python community. If you are not constrained to support legacy code, you may wish to browse the Python Package Index for alternatives to this module.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[R. David Murray]

I don't like any of the suggested wordings.  I have no problem with
us recommending other modules, but most of the Python libraries are
perfectly functional (not "leaky" or some other pejorative), they just
aren't as capable as the wiz-bang new stuff that's available on PyPI.

--David
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Eli Bendersky]

On Tue, Mar 13, 2012 at 05:07, R. David Murray <[hidden email]> wrote:
> I don't like any of the suggested wordings.  I have no problem with
> us recommending other modules, but most of the Python libraries are
> perfectly functional (not "leaky" or some other pejorative), they just
> aren't as capable as the wiz-bang new stuff that's available on PyPI.
>

 +1 to David's comment, and -0 on the proposal as a whole.

The suggested wordings are simply offensive to those modules & their
maintainers specifically, and to Python generally.

Personally, I think an intelligent user should realize that a
language's standard library won't provide all the latest and shiniest
gadgets. Rather, it will focus on providing stable tools that have
withstood the test of time and can serve as a basis for building more
advanced tools. That intelligent user should also be aware of PyPI
(and the main Python page makes it prominent enough), so I see no
reason explicitly pointing to it in the documentation of several
modules.

Eli
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[C. Titus Brown-2]

On Tue, Mar 13, 2012 at 05:22:45AM +0200, Eli Bendersky wrote:

> On Tue, Mar 13, 2012 at 05:07, R. David Murray <[hidden email]> wrote:
> > I don't like any of the suggested wordings. ?I have no problem with
> > us recommending other modules, but most of the Python libraries are
> > perfectly functional (not "leaky" or some other pejorative), they just
> > aren't as capable as the wiz-bang new stuff that's available on PyPI.
> >
>
>  +1 to David's comment, and -0 on the proposal as a whole.
>
> The suggested wordings are simply offensive to those modules & their
> maintainers specifically, and to Python generally.
>
> Personally, I think an intelligent user should realize that a
> language's standard library won't provide all the latest and shiniest
> gadgets. Rather, it will focus on providing stable tools that have
> withstood the test of time and can serve as a basis for building more
> advanced tools. That intelligent user should also be aware of PyPI
> (and the main Python page makes it prominent enough), so I see no
> reason explicitly pointing to it in the documentation of several
> modules.

I see the point, but as a reasonably knowledgeable Python programmer
(intelligent? who knows...) I regularly discover nifty new modules
that "replace" stdlib modules.  It'd be nice to have pointers in the
docs, although that runs the risk of having the pointers grow stale,
too.

--titus
--
C. Titus Brown, [hidden email]
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Eli Bendersky]

On Tue, Mar 13, 2012 at 05:25, C. Titus Brown <[hidden email]> wrote:

> On Tue, Mar 13, 2012 at 05:22:45AM +0200, Eli Bendersky wrote:
>> On Tue, Mar 13, 2012 at 05:07, R. David Murray <[hidden email]> wrote:
>> > I don't like any of the suggested wordings. ?I have no problem with
>> > us recommending other modules, but most of the Python libraries are
>> > perfectly functional (not "leaky" or some other pejorative), they just
>> > aren't as capable as the wiz-bang new stuff that's available on PyPI.
>> >
>>
>>  +1 to David's comment, and -0 on the proposal as a whole.
>>
>> The suggested wordings are simply offensive to those modules & their
>> maintainers specifically, and to Python generally.
>>
>> Personally, I think an intelligent user should realize that a
>> language's standard library won't provide all the latest and shiniest
>> gadgets. Rather, it will focus on providing stable tools that have
>> withstood the test of time and can serve as a basis for building more
>> advanced tools. That intelligent user should also be aware of PyPI
>> (and the main Python page makes it prominent enough), so I see no
>> reason explicitly pointing to it in the documentation of several
>> modules.
>
> I see the point, but as a reasonably knowledgeable Python programmer
> (intelligent? who knows...) I regularly discover nifty new modules
> that "replace" stdlib modules.  It'd be nice to have pointers in the
> docs, although that runs the risk of having the pointers grow stale,
> too.
>

Exactly. It's not the job of the core developers to keep track of the
latest and greatest gadgets and to diligently update the docs when
something new comes out. Note that "the latest and coolest" changes
frequently, so this may mean different "recommendations" between 3.x.y
and 3.x.y+1, which is even more confusing.

Wasn't a PyPI recommendation / voting system discussed a while ago?
*That* would be much more appropriate than officially endorsing
specific modules by pointing to them in the standard documentation.

Eli
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[C. Titus Brown-2]

On Tue, Mar 13, 2012 at 05:42:55AM +0200, Eli Bendersky wrote:

> On Tue, Mar 13, 2012 at 05:25, C. Titus Brown <[hidden email]> wrote:
> > I see the point, but as a reasonably knowledgeable Python programmer
> > (intelligent? who knows...) I regularly discover nifty new modules
> > that "replace" stdlib modules. ?It'd be nice to have pointers in the
> > docs, although that runs the risk of having the pointers grow stale,
> > too.
> >
>
> Exactly. It's not the job of the core developers to keep track of the
> latest and greatest gadgets and to diligently update the docs when
> something new comes out. Note that "the latest and coolest" changes
> frequently, so this may mean different "recommendations" between 3.x.y
> and 3.x.y+1, which is even more confusing.
>
> Wasn't a PyPI recommendation / voting system discussed a while ago?
> *That* would be much more appropriate than officially endorsing
> specific modules by pointing to them in the standard documentation.

I feel like there's a middle ground where stable, long-term go-to modules could
be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect
almost everyone spends a certain amount of time in the Python docs (which is a
testimony to their quality IMO).  So I'm in favor of conservative link-outs
but without any deprecating language.

--titus
--
C. Titus Brown, [hidden email]
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Brian Curtin]

On Mon, Mar 12, 2012 at 19:23, Andrey Petrov <[hidden email]> wrote:
> What such a snippet might look like:
>
> "Batteries are included with Python but sometimes they are old and
> leaky—this is one of those cases. Please have a look in PyPI for more modern
> alternatives provided by the Python community."

What does "leaky" mean here? Someone's going to see that, think it has
memory leaks, then rant on the internet about how we ship crap and
just document it as so.


> Part 2:
> I propose we add a new category of package identifiers such as "Topic ::
> Standard Library Alternative :: {stdlib_package_name}" which authors of
> libraries can tag themselves under. The documentation warning snippet will
> provide a link to the appropriate PyPI query to list packages claiming to be
> alternatives to the stdlib package in question.

Automating it to something on PyPI is the not the right answer. People
will use it incorrectly, either in that they'll add it to packages for
which it isn't accurate, and people just flat out won't use it or know
about it. It won't be accurate this way, and anything that we're
documenting needs to be vetted.

It's not often that a great alternative comes up, so I don't see the
manual burden being too great.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Glenn Linderman-3]

On 3/12/2012 8:48 PM, C. Titus Brown wrote:

I feel like there's a middle ground where stable, long-term go-to modules could
be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect
almost everyone spends a certain amount of time in the Python docs (which is a
testimony to their quality IMO).  So I'm in favor of conservative link-outs
but without any deprecating language.

Any outward links will be somewhat intrusive, and their existence will admit that the stdlib module is limited in some fashion, such that someone invested time and effort to create an alternative.

On the other hand, if there were a standard place for external links to alternatives, say, perhaps, at the bottom of the left-hand table of contents for the module, and if it were Wiki-like (anyone could add an alternative) then the core developers wouldn't need to monitor and approve the alternatives. The alternatives would not be listed in the TOC, only the link, if alternatives were submitted.  At the link target Wiki, there could be various alternatives, pro/con comments, user votes, whatever seems useful.

If there is truly a desire by core developers to recommend specific alternative modules, then wording like the following seems neutral to me:

Alternatives to this module exist at [list of links], which may be updated more regularly than the stdlib.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Andrey Petrov-2]

On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin <[hidden email]> wrote:

> On Mon, Mar 12, 2012 at 19:23, Andrey Petrov <[hidden email]> wrote:
>> What such a snippet might look like:
>>
>> "Batteries are included with Python but sometimes they are old and
>> leaky—this is one of those cases. Please have a look in PyPI for more modern
>> alternatives provided by the Python community."
>
> What does "leaky" mean here? Someone's going to see that, think it has
> memory leaks, then rant on the internet about how we ship crap and
> just document it as so.

I agree Brian and David, the choice of "leaky" in the wording is poor.
It was supposed to be maintaining the "batteries" metaphor but it's
clearly ambiguous.

Perhaps something along the lines of...

"Batteries are included with Python but for stability and backwards
compatibility, some of the standard library is not always as modern as
alternatives provided by the Python community—this is one of those
cases. Please have a look at PyPI for more cutting-edge alternatives."

>> Part 2:
>> I propose we add a new category of package identifiers such as "Topic ::
>> Standard Library Alternative :: {stdlib_package_name}" which authors of
>> libraries can tag themselves under. The documentation warning snippet will
>> provide a link to the appropriate PyPI query to list packages claiming to be
>> alternatives to the stdlib package in question.
>
> Automating it to something on PyPI is the not the right answer. People
> will use it incorrectly, either in that they'll add it to packages for
> which it isn't accurate, and people just flat out won't use it or know
> about it. It won't be accurate this way, and anything that we're
> documenting needs to be vetted.
>
> It's not often that a great alternative comes up, so I don't see the
> manual burden being too great.

There are a dozen or more urllib/httplib/pycurl competitors on PyPI,
and new ones spring up all the time. I'm not sure how we would go
about objectively blessing the best "official" option at any given
moment, or how frequently we would have to do this.

With self-identifying, we could sort by some sort metric (monthly
downloads? magical score?) and create a somewhat-actionable list.

- Andrey
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Terry Reedy]

On 3/12/2012 10:23 PM, 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.
>
>
> Part 1:
> I propose we add a snippet to the top of the documentation of specific
> archaic standard modules which encourages users to investigate
> third-party alternatives if they find the standard module frustrating or
> otherwise lacking. These notes would target new users, including those
> coming from other languages where the third-party library choices are
> not nearly as amazing as they are in Python.

I would rather we figure out how to encourage authors of advancing
packages to contribute better implementations of existing features and
well-tested new features back to the stdlib module.

For instance, are you the same 'Andrey Petrov' who is'darkprokoba' on
the tracker? As near as I can tell, that user has posted on one issue
about free threading and nothing else, in particular, nothing about
web protocols. If that is you, why not?

 > What such a snippet might look like:
 > "Batteries are included with Python but sometimes they are old and
 > leaky—this is one of those cases. Please have a look in PyPI for more
 > modern alternatives provided by the Python community."

You have every right to work independently. develop alternative modules,
and promote them. But suggesting that we denigrate our work to promote
yours strikes me as inappropriate. If nothing else, it would discourage
rather than encourage more contributions from more people.

 > Additionally, I would like for us as a community to identify which
 > other standard libraries (cgi? ssl? others?) are candidates for this
 > kind of messaging in the official Python documentation.

To the degree feasible, stdlib modules should be the best possible in
the area they cover. Then all who install Python would benefit. Do you
disagree? I would like more of the community to help make that happen.

Any messages in the stdlib doc should be about modules that do things
intentionally not covered in the stdlib.

--
Terry Jan Reedy


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Brian Curtin]

On Mon, Mar 12, 2012 at 21:14, Andrey Petrov <[hidden email]> wrote:

> On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin <[hidden email]> wrote:
>> On Mon, Mar 12, 2012 at 19:23, Andrey Petrov <[hidden email]> wrote:
>>> What such a snippet might look like:
>>>
>>> "Batteries are included with Python but sometimes they are old and
>>> leaky—this is one of those cases. Please have a look in PyPI for more modern
>>> alternatives provided by the Python community."
>>
>> What does "leaky" mean here? Someone's going to see that, think it has
>> memory leaks, then rant on the internet about how we ship crap and
>> just document it as so.
>
> I agree Brian and David, the choice of "leaky" in the wording is poor.
> It was supposed to be maintaining the "batteries" metaphor but it's
> clearly ambiguous.
>
> Perhaps something along the lines of...
>
> "Batteries are included with Python but for stability and backwards
> compatibility, some of the standard library is not always as modern as
> alternatives provided by the Python community—this is one of those
> cases. Please have a look at PyPI for more cutting-edge alternatives."

Sorry for another color choice on the bikeshed, but I would drop the
word or references to "batteries". *We* know what "batteries included"
means, but there are undoubtedly people who won't get it. It's just
code - let's call it code.

>>> Part 2:
>>> I propose we add a new category of package identifiers such as "Topic ::
>>> Standard Library Alternative :: {stdlib_package_name}" which authors of
>>> libraries can tag themselves under. The documentation warning snippet will
>>> provide a link to the appropriate PyPI query to list packages claiming to be
>>> alternatives to the stdlib package in question.
>>
>> Automating it to something on PyPI is the not the right answer. People
>> will use it incorrectly, either in that they'll add it to packages for
>> which it isn't accurate, and people just flat out won't use it or know
>> about it. It won't be accurate this way, and anything that we're
>> documenting needs to be vetted.
>>
>> It's not often that a great alternative comes up, so I don't see the
>> manual burden being too great.
>
> There are a dozen or more urllib/httplib/pycurl competitors on PyPI,
> and new ones spring up all the time. I'm not sure how we would go
> about objectively blessing the best "official" option at any given
> moment, or how frequently we would have to do this.

The same way we choose to accept libraries into the standard library.
New ones spring up all the time - mature, proven, and widely used ones
do not. If someone thinks libfoo is ready, they suggest it. If we
haven't heard of it, the conversation ends. If we have people who know
it, maybe we have them look deeper and figure out if it's something we
can put our stamp on just like we might with the recent talk of
"experimental package" inclusion.

> With self-identifying, we could sort by some sort metric (monthly
> downloads? magical score?) and create a somewhat-actionable list.

Downloads don't mean the code is good. Voting is gamed. I really don't
think there's a good automated solution to tell us what the
high-quality replacement projects are.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Guido van Rossum]

On Mon, Mar 12, 2012 at 9:22 PM, Terry Reedy <[hidden email]> wrote:
> I would rather we figure out how to encourage authors of advancing packages
> to contribute better implementations of existing features and well-tested
> new features back to the stdlib module.

I would not. There are many excellent packages out there that should
not be made into stdlib packages simply because their authors are not
done adding new features. If you contribute something to the stdlib
and also maintain a non-stdlib version of the same code to which you
regularly add features, your code is not ready for inclusion into the
stdlib. Not only should you be willing to wait 18 months (until the
next feature release) before your features are released, but you
should also accept that only the latest version of Python will see
those features.

This obviously makes it very unattractive for many authors to ever
contribute to the stdlib. That's fine. There's a healthy ecosystem of
3rd party modules. For some areas (web stuff especially) there's just
no way that the stdlib can keep up. Yes, the stdlib offerings work.
But no, they are not very convenient and may not support popular
idioms very well. For these types of modules I think it is a good idea
to place some sort of pointer in the stdlib docs to an external page
(maybe a wiki page) that collects a currently popular set of
alternatives, or perhaps a few pointers and wiki pages. We should
still be conservative with this, and we should word it to avoid
implying that the stdlib code is buggy -- it just isn't as spiffy or
featureful as the 3rd party options.

(Agreed that the "leaky" wording was unfortunate. I may have
inadvertently suggested this, taking the analogy with "batteries
included". But I didn't mean it to be literally included into the
stdlib.)

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Guido van Rossum]

On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin <[hidden email]> wrote:
> Downloads don't mean the code is good. Voting is gamed. I really don't
> think there's a good automated solution to tell us what the
> high-quality replacement projects are.

Sure, these are imperfect metrics. But not having any metrics at all
is flawed too. Despite the huge flamewar we had 1-2 years ago about
PyPI comments, I think we should follow the lead of the many app
stores that pop up on the web -- users will recognize the pattern and
will tune their skepticism sensors as needed.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Eli Bendersky]

On Tue, Mar 13, 2012 at 06:43, Guido van Rossum <[hidden email]> wrote:

> On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin <[hidden email]> wrote:
>> Downloads don't mean the code is good. Voting is gamed. I really don't
>> think there's a good automated solution to tell us what the
>> high-quality replacement projects are.
>
> Sure, these are imperfect metrics. But not having any metrics at all
> is flawed too. Despite the huge flamewar we had 1-2 years ago about
> PyPI comments, I think we should follow the lead of the many app
> stores that pop up on the web -- users will recognize the pattern and
> will tune their skepticism sensors as needed.
>

An additional bonus of such a system is that we won't have to maintain
a separate Wiki page with "popular" choices. Pointing to the PyPI
"rating" page, which can presumably be filtered by tags (i.e. web,
scientific, XML, etc.) should be sufficient, given that such a rating
page exists.

Eli
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Matt Joiner]

Definitely think some library vetting needs to occur. Superior alternatives do exist and are difficult to find and choose from. Stuff like LXML, Requests, Tornado are clear winners.

The more of this done externally (ie PyPI the better). I still think a set of requirements for "official approval" would be good. This could outline things like requiring that certain stable Python versions are supported, interface stability, demonstrated user base, documentation etc.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Senthil Kumaran-7]

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.

--
Senthil

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Andrey Petrov-2]

Dear authors of Python's standard library: Please accept my deepest
apologies. We didn't mean for the messaging to come off as
unappreciative for you work, and I am very sorry for that!

Without the aforementioned urllib/httplib/etc I would have never made
it as far as to build my own libraries which have suited my needs
better than the foundations that originally allowed me to get off the
ground. I am very grateful for all of those responsible for building
the Python standard library and I appreciate your continued efforts.

Some specific replies:

@Senthil: I originally asked Guido for guidance on improving the
standard library and perhaps including some of my favourite projects,
but he pointed out that in a couple of years we might end up again in
the same position as before but with one extra library people will
complain about for being obsoleted yet remains impossible to
deprecate.

I agreed with Guido that embracing and even encouraging users to use the
rapidly-evolving community-built packages alongside the tried-and-true
standard library is the best move here.

@Terry: I don't know who 'darkprokoba' is. Unfortunately 'Andrey
Petrov' is a very common name. I go under the handle 'shazow' but I
haven't participated in core Python discussions until today.

I did not suggest for Python to endorse a specific module, even if it
is my own. In fact, I generally oppose doing this as I feel that when
Django was announced as the blessed 'winner' of the Python MVC
frameworks was a harmful event to all other competing frameworks at
the time.

My suggestion is to inform the users when there are other potentially
better suited alternatives available from the community PyPI and to
educate them how to find these alternatives.

- Andrey
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Senthil Kumaran-7]

On Mon, Mar 12, 2012 at 10:48:04PM -0700, Andrey Petrov wrote:

> @Senthil: I originally asked Guido for guidance on improving the
> standard library and perhaps including some of my favourite projects,
> but he pointed out that in a couple of years we might end up again in
> the same position as before but with one extra library people will
> complain about for being obsoleted yet remains impossible to
> deprecate.
>
> I agreed with Guido that embracing and even encouraging users to use the
> rapidly-evolving community-built packages alongside the tried-and-true
> standard library is the best move here.

I agree with that too.

I think, any improvements which can made by external libraries, if
they can be considered as can be good improvement in the stdlib, It's
a good idea to push them in.

I looked at the requests, I think that apis for various HTTP verbs is
something interesting, I think web applications authors see some
advantage there explicit GET / POST and sending specific options to
those. That facility, if it can be brought into urllib.request (3.3
onwards) it could be nice. Also you could have noticed an addition of
method= parameter in 3.3

I have not had a chance to look at urllib3. Should do. I have been
following httplib2 and use it.

Thanks,
Senthil


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Paul Moore]

On 13 March 2012 03:48, C. Titus Brown <[hidden email]> wrote:
> I feel like there's a middle ground where stable, long-term go-to modules could
> be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect
> almost everyone spends a certain amount of time in the Python docs (which is a
> testimony to their quality IMO).  So I'm in favor of conservative link-outs
> but without any deprecating language.

I applaud the idea of promoting the many excellent packages available.
It can be very hard to separate the good from the indifferent (or even
bad) when browsing PyPI. I've found some very good packages recently
which I'd never have known about without some random comment on a
mailing list.

However, I'm not keen on having the stdlib documentation suggest that
I should be using something else. No code should ever be documenting
"don't use me, there are better alternatives" unless it is deprecated
or obsolete.

On the other hand, I would love to see a community-maintained document
that described packages that are acknowledged as "best of breed". That
applies whether or not those packages replace something in the stdlib.
Things like pywin32, lxml, and requests would be examples in my
experience. There's no reason this *has* to be in the core
documentation - it may be relevant that nothing has sprung up
independently yet...

Maybe a separate item in the Python documentation, "External Modules",
could be created and maintained by the community? By being in the
documentation, it has a level of "official recommendation" status, and
by being a top-level document it's visible (more so than, for example,
a HOWTO document would be). Because it's in the released
documentation, it is relatively stable, which implies that external
modules would need to have a genuine track record to get in there, but
because it's community maintained it should reflect a wider consensus
than just the core developers' views.

Paul.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com

[Donald Stufft]

On Tuesday, March 13, 2012 at 9:31 AM, Paul Moore wrote:

On 13 March 2012 03:48, C. Titus Brown <[hidden email]> wrote:

I feel like there's a middle ground where stable, long-term go-to modules could

be mentioned, though.  I don't spend a lot of time browsing PyPI, but I suspect

almost everyone spends a certain amount of time in the Python docs (which is a

testimony to their quality IMO).  So I'm in favor of conservative link-outs

but without any deprecating language.

I applaud the idea of promoting the many excellent packages available.

It can be very hard to separate the good from the indifferent (or even

bad) when browsing PyPI. I've found some very good packages recently

which I'd never have known about without some random comment on a

mailing list.

However, I'm not keen on having the stdlib documentation suggest that

I should be using something else. No code should ever be documenting

"don't use me, there are better alternatives" unless it is deprecated

or obsolete.

On the other hand, I would love to see a community-maintained document

that described packages that are acknowledged as "best of breed". That

applies whether or not those packages replace something in the stdlib.

Things like pywin32, lxml, and requests would be examples in my

experience. There's no reason this *has* to be in the core

documentation - it may be relevant that nothing has sprung up

independently yet...

http://python-guide.org ?

Maybe a separate item in the Python documentation, "External Modules",

could be created and maintained by the community? By being in the

documentation, it has a level of "official recommendation" status, and

by being a top-level document it's visible (more so than, for example,

a HOWTO document would be). Because it's in the released

documentation, it is relatively stable, which implies that external

modules would need to have a genuine track record to get in there, but

because it's community maintained it should reflect a wider consensus

than just the core developers' views.

Paul.

_______________________________________________

Python-Dev mailing list

[hidden email]

http://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com