On Sep 19, 2014, at 5:26, Paul Moore email@example.com wrote:
On 19 September 2014 12:59, Steven D'Aprano firstname.lastname@example.org wrote:
Now obviously there are "best of breed" third party libraries. I don't see many people trying to build a better BeautifulSoup. (Maybe they are, and I just don't know about them, which demonstrates the problem.) That's not necessarily a bad thing. But I think we should be careful of putting the thumb on the scales too much.
Agreed. I hadn't considered the point about discouraging innovation. So it seems to me that the key things needed are:
- Discoverability - making it easy for package authors to ensure
people find their packages. There's a social aspect here as well - quirky project names like celery or freezegun are a part of the Python culture, but they do make things less discoverable (what do those two projects do?). We need a way to balance that.
There's more to it. Many of the most important packages are doing something that didn't have a category until they invented it. For example, what is BeautifulSoup exactly? Originally, IIRC, it was intended to be a more lenient HTML parser. But nowadays it doesn't even do the parsing itself; it drives a stdlib or other third-party parser. It's sort-of a better (than what?) DOM interface for HTML and XML, which is something no one realized they needed until it existed. If the Python community had the kind of less-fanciful, easier-to-find, specific names that, say, perl has, what would it be called? HTML::Parsers::TagSoupParser?
Also, the boring names tend to mean that, when there _is_ an obvious category, the first entrant stakes out the best name, and everyone else ends up with just less-felicitous variants of the same name. The fact that SleekXMPP and Wokkel replaced Jabberpy as the most popular XMPP libraries means that it's pretty easy for me to recommend SleekXMPP over Jabberpy. In another language, you have to tell people to use libXMPPClient or XMPPLib instead of libXMPP.
- A clearer way for projects to declare what they support. Python 2
or 3 or both? Is Windows supported? And it's not just "yes or no", often it's somewhere in the middle - for example I know projects that want to work on Windows, but don't have the expertise, so they'll accept patches but you have to expect to do some of the work for them... Classifiers should do this, but use is patchy (particularly around the supported OS). 3. Most controversially, some way of rating otherwise-equal packages. Ultimately, I don't want a choice, I just want to install something and move on. Download counts may be the easiest compromise here (at least lots of people use the project...)
As well as the technical aspect of making it possible to provide this information (much of it, projects *can* provide right now, although maybe not always as easily as might be ideal) there is a social aspect
- making it so that it's the norm for projects to do so, and not doing
so is viewed as an indication of overall attention to detail on the project.
Paul _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/