pyscript's first README line is maintenance mode, and its version lives in your HTML

The first line of the README is a maintenance announcement

Above the logo, above the example, above everything, the README has an announcement section whose whole content is one line and a link: PyScript is entering maintenance mode, linking to a note on gist.github.com under the WebReflection account.

That placement is the point.

The release history is consistent with the announcement rather than in tension with it. The three most recent tags are 2026.7.1 on 2026-07-01, 2026.7.2 on 2026-07-09 and 2026.7.3 on 2026-07-29, and the last push to the default branch was on 2026-10-05. So there has been no release since the end of July, and the branch has moved since, which is what maintenance mode looks like from the outside.

The versioning is calendar based, year and month, so the current line is 2026.7 and an October push produced no 2026.10 tag. For a reader pinning a version, that is the practical meaning of the announcement: the last published build is 2026.7.3.

The version is a literal string in your markup

The example page in the README loads two files and the version number is in both:

        <link
            rel="stylesheet"
            href="https://pyscript.net/releases/2026.7.3/core.css"
        />
        <script
            type="module"
            src="https://pyscript.net/releases/2026.7.3/core.js"
        ></script>

There is no package manager step, no manifest and no lockfile. The runtime is a script tag, and pinning it is a text edit.

That has one clearly good consequence. The path is `releases/<version>/`, so every historical release remains addressable by changing the number in the URL. Given the maintenance announcement, that is the most valuable property of the whole design: a project that has stopped shipping new versions can still hand you the exact version you tested, indefinitely, without an archive of your own.

The cost is on the other side. Your page fetches its runtime from somebody else's static host at load time, and the only thing tying a page to a version is a string you have to remember to update. Two pages in the same project can run different PyScript versions, and nothing in the markup records why.

One type attribute picks MicroPython or Pyodide

The Python block in the example carries a comment that is really the whole API:

        <!-- type mpy (MicroPython) or py (Pyodide) to run some Python -->
        <script type="mpy" terminal>
            print("Hel

Two attributes do the work. The `type` selects the runtime, `mpy` for MicroPython and `py` for Pyodide, and `terminal` turns the block into an interactive terminal rather than something that runs once on load.

The two runtimes are not variations on a theme. Pyodide is described as a version of CPython, so it brings the standard library with it, which is why it is the heavier of the two. MicroPython is a small interpreter, which is the point of offering it at all: a lighter runtime than Pyodide.

Because the choice is per script, a page is not limited to one. A page that needs the standard library in one component and a small footprint in another can express both, which is a real capability and also a source of confusion, since a package that works under `py` will not under `mpy` and the failure is at runtime rather than at load.

There is no install, and the runtime is somebody else's CDN

The README contains no install command and no package to add. A page includes a stylesheet and a module script, and that is the whole of the installation.

The related decision is that `pyscript.net` serves the files. So a page using PyScript depends on a third party's static hosting being reachable and unchanged at the moment a user loads it, and the version URL is the only control a page has over what it gets.

This is a reasonable trade for the use case the project describes, which is a Python application in a browser with modern web technologies around it, on desktop, laptop, mobile or tablet. It is a poor fit for a deployment that has a strict supply-chain policy, because there is no package to inspect, no integrity hash to pin and no lockfile to commit. A team with that policy wants the two files mirrored into its own asset pipeline, which the versioned path makes straightforward and which nothing in the README asks you to do.

The alternative shape of the same technology is a build step. The README does not offer one, and the online IDE at `pyscript.com` is a hosted service rather than a local bundler.

The online IDE is a hosted service, not the open source project

The README lists several resources and they are worth separating, because trying the project and adopting it are different paths.

The home page is `pyscript.net/`, the technical documentation is at `docs.pyscript.net/`, and the project describes itself there as an open source project. Then there is a free-to-use online IDE at `pyscript.com/`, an example applications gallery at `pyscript.com/@examples`, a YouTube channel, and a Discord channel.

So `pyscript.net` is the project and `pyscript.com` is a hosted place to try it and to browse examples. The distinction matters in maintenance mode, because the examples gallery is the fastest way to see what the platform can still do, and it is a hosted site rather than something in the repository.

The community structure is also concrete. There is a PyScript Community Call on Zoom every Tuesday at 15:30 UTC, where most maintainers regularly participate and which is recorded and uploaded to the YouTube channel. There is a PyScript FUN call every other Thursday at 16:00 UTC, focused on fun projects, goofy hacks and clever uses, also recorded. Both schedules are published as a Google calendar in UTC and as an iCal file.

Governance is in a file and in a second repository

A maintenance-mode announcement is exactly the moment when governance becomes the thing a reader should check, and this repository has unusually much of it in view.

There is a `GOVERNANCE.md` at the root, and there is also a separate governance repository, linked from the README as the PyScript organization governance, which is documented in a distinct place. Alongside those are `MAINTAINERS.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and a `.pre-commit-config.yaml`.

The README points to the separate repository for organisation governance and does not say what the root GOVERNANCE.md adds. The maintainer list is its own file rather than a section of the README.

The README also points contributors at a `core/README.md` for the technical details of the code, and the README links the contributing guide and a development process document on the documentation site, although a CONTRIBUTING.md also sits at the repository root. So the project is explicit about which file answers which question, which is worth more than usual when a reader is deciding whether to depend on something long term.

The core contributors are employed by Anaconda

The Supporters section is short and its second sentence is the one that matters:

PyScript is an independent open source project. However, PyScript was born at Anaconda Inc and its core contributors are currently employed by Anaconda to work on PyScript.

So the project describes itself as independent of a company, and its core maintainers are paid by that company to work on it. Both halves are stated, and the acknowledgement asks readers to celebrate Anaconda's continued support.

In maintenance mode that combination is the thing to weigh. The people making the announcement are, by the project's own account, employees of a company whose product line includes Python distribution. A reader deciding whether the platform will keep existing in ten years is really asking whether that employment continues, and the repository gives no answer to that beyond the statement itself.

The governance file and the governance repository are where to look for how such a decision would be made. The Apache-2.0 licence means the code itself is not the constraint; a fork is always available. What a fork does not carry is the community around the code.

The Python in this repository formats the JavaScript and nothing else

The requirements file is four packages, and none of them is a Python library that ships in the browser:

black==26.1.0
pre-commit==4.5.1
python-minifier==3.2.0
setuptools==82.0.0

`black` formats Python source, `pre-commit` runs the hooks, `setuptools` is Python packaging tooling, and `python-minifier` minifies Python. Three of the four exist to keep the tooling tidy.

So the product is not Python. The top level holds `core/`, `bridge/` and `public/`, and the Makefile's setup step does `cd core && npm ci`, which is where the JavaScript project lives. There is no top level `package.json`. The Python in this repository maintains and compresses the code that runs in a browser, and that is a much smaller role than a reader arriving at a project called PyScript might expect.

Two more details are worth having. The `pyproject.toml` configures ruff with a line length of 114, a broad select list and a max complexity of 27, alongside codespell with an ignore list containing one word and skipping JavaScript and JSON. So Python is linted by ruff and formatted by black, which is a common pairing. And the Makefile has no default target: running `all` prints a menu of the other targets, which is a small courtesy that tells you the author expected people to be lost.

Editorial conclusion

PyScript fits someone who wants Python in an existing page without a build step, who is content to pin a version by editing a URL, and who needs either a full CPython standard library through Pyodide or a small MicroPython interpreter in a script tag. It does not fit a team that needs an actively developed platform, since the project says it is entering maintenance mode, or one that wants a dependency-managed runtime, since there is no package manifest and no lockfile. Before adopting, check three things: the maintenance announcement at the top of the README and what it means for the release channel, the size of the runtime you actually need, because MicroPython and Pyodide are a per-script `type` attribute apart, and whether you can host the two CDN files yourself rather than depending on `pyscript.net` at page load.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. pyscript/pyscript on GitHub
4. README
5. Releases