best-of-web-python: a ranked index of 590 Python web projects

What best-of-web-python actually solves

Searching PyPI for a Python web library returns thousands of packages with no ordering signal beyond a download count. best-of-web-python compresses that space into 590 projects sorted into 26 categories, from Web Frameworks and HTTP Clients to Django Utilities and Web Scraping. The README states the list is ranked by a project-quality score calculated from metrics collected automatically from GitHub and different package managers. That is the whole product: a pre-filtered shortlist with a numeric ordering.

The audience is narrower than the name suggests. It is useful to an engineer who already knows Django or FastAPI and needs to find the library layer underneath: an OpenAPI utility, a GraphQL helper, an authentication package. It is not a tutorial, not a comparison with benchmarks, and not a substitute for reading a candidate's own documentation. The categories are the real navigational device. A reader who jumps straight to the numbered ranking is using the list wrong.

How the project-quality score and the symbols work

Each entry is a collapsed block that expands to reveal per-source install commands. The README's explanation section defines the symbols attached to every project: a combined quality score shown as medal emoji, star count from GitHub, a new-project marker for anything under six months old, an inactive marker at six months without activity, a dead marker at twelve months, trending up or down arrows, a recently-added marker, a warning symbol for missing or risky licences, contributor and fork counts, issue count, last package-manager update timestamp, download count, and dependent-project count.

The score itself is not published as a formula in the README. What is visible is the input set: GitHub metrics plus package manager metrics. That means the ordering tracks popularity and maintenance signals, and a small library that solves one problem well will rank below a large framework with heavy download traffic. The inactive and dead markers are the more honest part of the system, because they tell you when a high-scoring project has stopped moving. The README does not document how the weights are set or how ties are broken, so treat the number as a coarse sort, not a measurement.

Installing nothing: using the list as a first step

There is no package to install. The list lives in the repository and on the homepage at web-python.best-of.org, and the README points contributors at projects.yaml as the file to edit. The practical first use is to clone the repository and read the data file directly, which is faster than expanding hundreds of collapsed sections in a browser.

The clone command is the one the README gives for Django, but the same form works for the list repository itself:

git clone https://github.com/ml-tooling/best-of-web-python

After cloning, projects.yaml is the machine-readable source behind every rendered entry. Reading it directly returns the projects grouped by category without any browser rendering:

cat projects.yaml

For a single candidate, the README shows the per-source install commands inside each collapsed entry. The Django entry, for example, lists a PyPI path and a Conda path:

pip install django
conda install -c conda-forge django

What you should see after reading projects.yaml is the category headings and the entries beneath them. If you want to add or correct a project, the README directs you to open an issue, submit a pull request, or edit projects.yaml directly.

Where the ranking misleads you

The score mixes maintenance signals with popularity signals, and those are not the same question. A project can be actively pushed to and still be the wrong choice for a production service, and a project can sit at a low rank because it has a small user base while being exactly the right tool. The README gives no per-project evaluation of code quality, API stability or security posture, so a high medal count carries no information about whether the library will break on upgrade.

The freshness markers have a similar limit. The inactive threshold is six months without activity and the dead threshold is twelve, both judged from repository activity. A library that is feature-complete and needs no changes will eventually be labelled inactive even though nothing is wrong with it. The README does not document rollback, deprecation policy or support windows for the projects it lists, because it is not the maintainer of any of them. If you need a guarantee about long-term support, this list cannot give it to you.

How it differs from a curated awesome list

A conventional awesome list is a hand-ordered set of links with prose annotations. best-of-web-python keeps the curation but replaces the ordering with an automated score, and it stores the data in projects.yaml rather than in prose. That is the real difference in approach: contributions change structured data, and the rendered README is generated from it, which is why the repository ships a config directory and a history directory alongside the data file.

The trade-off is that automated scoring cannot express judgement. A hand-written list can say a library is unmaintained but still the only option for a niche protocol. A score can only move the project down. Conversely, the generated list scales to 590 entries across 26 categories in a way manual ordering does not, and the weekly update cadence means the install commands and timestamps stay current. If you want opinions, a written awesome list is better. If you want coverage and a sortable signal, this format wins.

Licence and what the CC-BY-SA-4.0 covers

The repository itself is licensed CC-BY-SA-4.0, which is a content licence rather than a software licence. It covers the list: the README text, the category descriptions, the ranking presentation. It does not cover the 590 projects it links to, each of which carries its own licence shown inline in the entry, such as BSD-3 for Django and Flask or MIT for FastAPI in the README's own examples.

That distinction matters if you plan to reuse the list. Copying the README into internal documentation brings the attribution and share-alike terms of CC-BY-SA-4.0 with it. Copying a library into your application brings that library's licence instead, and the list's warning symbol exists precisely because some entries have missing or risky licences. The README does not give legal guidance, and the licence shown next to an entry is a pointer to verify at the source, not a clearance.

Maintenance and the cost of following it

The repository is not archived, and the last push was on 2026-09-17. Releases follow a roughly weekly rhythm in the recent history: 2026.08.20, 2026.08.28 and 2026.09.10. That cadence is the upgrade cost. If you pin your reading to a release tag, you re-read a diff of ranking changes every week or so, most of which are timestamp and download-count noise rather than new projects.

For most readers the sensible pattern is to consume the list at the moment of a decision and ignore the release stream in between. The history directory and latest-changes.md exist for exactly that: they record what moved without requiring you to diff the whole README. There is no migration burden because nothing installs, but there is a reading burden, and it grows with the list. The README does not describe a stable interface for programmatic consumption, so anyone parsing projects.yaml should expect the schema to change with the weekly updates.

Editorial conclusion

Use best-of-web-python when you need a shortlist of Python web libraries you have not heard of, and treat the ranking as a filter rather than a verdict. Skip it if you need benchmark numbers or a maintained recommendation for a specific stack, because the score reflects repository and package-manager metrics, not runtime behaviour. Before adopting anything from it, open the candidate's own repository and check its licence and last release date, then read the category in projects.yaml to see which projects sit next to it.

Frequently asked questions

Official sources

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