[Python-ideas] The stdlib++ user experience (Was: Introduce `start=1` argument to `math.factorial`)

Paul Moore p.f.moore at gmail.com
Fri Sep 19 14:26:53 CEST 2014


On 19 September 2014 12:59, Steven D'Aprano <steve at pearwood.info> 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:

1. 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.
2. 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


More information about the Python-ideas mailing list