best-of-python: a ranked index of 400 Python libraries, and how to read its scores

What best-of-python solves, and who it is aimed at

Picking a Python library for a task you rarely touch is slow. Search results are dominated by SEO pages, and the ones that are not are usually unranked link dumps where a 15-year-old project sits next to one released last month. best-of-python addresses that by putting a number next to each entry. The README describes the list as a curated set of 400 open source projects with a total of 2.1M stars, grouped into 28 categories, with each project ranked by a project-quality score calculated from metrics collected automatically from GitHub and various package managers.

The audience is the engineer who has to choose between, say, orjson and a stdlib json path, or between two configuration libraries, and wants a category view before committing. The README gives a concrete example of the format: orjson is listed under Data Serialization with a quality score of 34, a star count of 8.2K, a contributor count of 24, and a PyPi download figure of 190M per month. Every entry follows that shape, so scanning a category is fast.

What it is not is a review site. Nothing in the README explains the weights behind the score, and the entries carry no prose evaluation of API design, maintenance burden or breaking-change history. The list tells you which projects other people depend on. It does not tell you whether the project fits your code.

How the ranking is generated and what the weekly release actually contains

The repository is a generator, not a hand-maintained document. The top level holds projects.yaml, config/, history/ and latest-changes.md alongside the README. Entries are added or edited by changing projects.yaml, which the README points contributors to directly, and the README states that contributions can also arrive as issues or pull requests.

The ranking input is external: metrics collected automatically from GitHub and package managers. The badges on each entry show which dimensions are captured. For protobuf, the entry lists a GitHub clone command with 1.5K contributors, 16K forks and 1M dependent projects, a PyPi install with 670M downloads per month and 13K dependents, a Conda install with 36M downloads, and an npm install with 24M monthly downloads. The score of 40 is a compression of that set, not a measurement of code quality.

Releases are dated snapshots. The recent release tags follow the pattern 2026.09.17, 2026.09.10 and 2026.08.27, which matches the README's claim of a weekly update. The last push to the repository was on 2026-09-17. The history/ directory and latest-changes.md exist to record what moved between those snapshots, which is the practical way to see a project enter or leave a category without diffing the README by hand.

The explanation block defines the entry symbols: medals for the combined quality score, stars from GitHub, a chick for projects less than 6 months old, a sleeping symbol for inactive projects with 6 months of no activity, a skull for dead projects with 12 months of no activity, trending arrows, a plus for recently added entries, a warning for missing or risky licences, and counts for contributors, forks and issues. Those flags are the most useful part of the entry, because they are the only place where the list makes a negative statement about a project.

Installing best-of-python and pulling a category from projects.yaml

There is no package to install. The README points at the hosted list at python.best-of.org and at the repository, and the contribution path is to edit projects.yaml. So the first real use is cloning the repository and reading the YAML that produces the README.

Start with the clone, which is the same command the README shows for the projects it indexes:

git clone https://github.com/lukasmasuch/best-of-python
cd best-of-python

You should end up with projects.yaml, config/, history/, latest-changes.md and README.md at the top level. The README is generated from projects.yaml, so the YAML is the file to trust when the rendered list and your expectations disagree.

If you want to see what changed in the most recent weekly snapshot rather than read the whole list, the repository keeps a changelog:

cat latest-changes.md

That file is the fastest way to spot a project that was recently added or that gained an inactivity flag. For a single project's install command, the README embeds it under the entry, for example the PyPi line for orjson:

pip install orjson

Copy those commands from the entry rather than retyping them, since the list records the package name as published on the package manager. If you want to propose a project, the README says to open an issue, submit a pull request, or edit projects.yaml directly through the GitHub edit link.

The quality score is opaque, and that is the main limitation

The score is the product, and it is the least documented part of the repository. The README says it is calculated based on various metrics automatically collected from GitHub and different package managers. It does not publish the formula, the weights, or how a project with no package manager presence is treated relative to one published on PyPi and Conda.

That matters because the score rewards distribution. protobuf's 40 comes with 670M monthly PyPi downloads and 1M dependent projects. A well-designed library used inside a single company, with no PyPi release and no dependents, cannot score well no matter how good it is. The ranking is a popularity-and-packaging index, and reading it as anything else will mislead you.

The staleness flags are where the list is more honest. The README defines a sleeping symbol for 6 months of no activity and a skull for 12 months, and a warning symbol for missing or risky licences. Those are direct statements about a project's state, not composite scores, and they are the entries worth filtering on first. Note that the thresholds are activity-based, not release-based: a project that ships rarely but is still pushed to will not be flagged, and one that has been quiet for half a year will be, even if it is feature-complete by design.

The list is also curated by hand at the point of entry. projects.yaml is edited by contributors, so inclusion is a human decision even though the ordering is automatic. A category with four projects, such as Algorithms & Design Patterns or Process Utilities, reflects what someone chose to add, not an exhaustive survey.

How it differs from an awesome list or a search-driven pick

The obvious alternative is the plain awesome-list format: a hand-written README of links with short descriptions and no ordering. The difference is mechanical. An awesome list is edited by humans and stays static between edits; best-of-python regenerates on a weekly cadence, as the 2026.09.17, 2026.09.10 and 2026.08.27 release tags show, and each entry carries live counts from GitHub and package managers. If you want a stable, opinionated shortlist written by a maintainer, an awesome list gives you that. If you want to see which projects in a category are actually being installed and depended on this month, the generated list is the better instrument.

The second alternative is to skip curated lists and read package manager download counts or search results directly. That gives you the raw signal without the score, which some engineers prefer, but it also drops the category structure and the inactivity flags. The trade-off is real in both directions: best-of-python saves you the aggregation work and asks you to trust a composite you cannot inspect, while doing it yourself costs time and gives you the underlying numbers.

The category counts are worth reading as a signal in themselves. Database Clients has 64 projects and Data Pipelines & Streaming has 44, while Web Development and Machine Learning & Data Engineering each have 1. That is not a claim about the Python ecosystem; it is a claim about what the contributors to projects.yaml have chosen to index. Treat sparse categories as under-curated rather than as evidence that few options exist.

Editorial conclusion

Use best-of-python when you need a shortlist of Python libraries in a category you do not know well, and treat the ranking as a starting point for reading each project's own README rather than as a verdict. Do not use it as a substitute for evaluating a dependency yourself, and do not rely on the score to tell you whether a library is a good fit for your constraints. Before adopting anything from the list, open the project's own repository and check its release history, its licence, and whether the install command shown under its entry still resolves.

Frequently asked questions

Official sources

1. License: CC-BY-SA-4.0
2. lukasmasuch/best-of-python on GitHub
3. Project website
4. README
5. Releases