I think the cheesehop trove classifiers would be the ideal way to agnostically link to a page of packages related to the standard package in question. No need for sort order.
The beauty of this solution is that packages that aren't maintained won't add the appropriate classifier to their package, and therefore not show up in the list. -- Kenneth Reitz On Monday, March 12, 2012 at 9:23 PM, Brian Curtin wrote: > On Mon, Mar 12, 2012 at 21:14, Andrey Petrov <sha...@gmail.com > (mailto:sha...@gmail.com)> wrote: > > On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin <br...@python.org > > (mailto:br...@python.org)> wrote: > > > On Mon, Mar 12, 2012 at 19:23, Andrey Petrov <sha...@gmail.com > > > (mailto:sha...@gmail.com)> 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
