Discussions are open. This is the place for questions, ideas, and showing what you have made.
A Python notebook that runs entirely in your browser through WebAssembly (Pyodide), with no execution backend, no account, and no install. Open pynote-notebook.vercel.app and start writing Python. Your code and data stay on your machine, because there is no server to send them to.
| Where | What for |
|---|---|
| Q&A | How do I...? Answers here are searchable, so they help the next person too. |
| Ideas | Feature ideas and rough thoughts, including the half-formed ones you are not sure about yet. |
| Show and tell | Notebooks you have written, themes you have built, anything you have made with pynote_ui. |
| General | Everything else. |
| Issues | Bugs, enhancements, documentation, and questions all have a form in the issue chooser. |
Both the categories here and the issue forms are meant to be loose. Describe things in your own words. You do not need to work out which file is responsible or use any particular terminology, and you do not need to agonize over whether something is a discussion or an issue, since either one can be moved later.
Screenshots, pictures, GIFs, recordings, sketches, and example notebooks are welcome. They often explain a problem or an idea faster than text does.
The tutorial is a notebook that runs inside the app, so you can edit and run every example as you read it. There is also an interactive interview coding preparation series if you want something more practical to work through.
Two shortcuts worth knowing right away. Ctrl-\ opens the full shortcut list, and Ctrl-. opens the Files and Data panel where you can upload files and read them from Python.
A few things people usually do not expect to find in a browser notebook: interactive UI components built straight from Python with pynote_ui, a marimo-style reactive execution mode alongside three manual ones, a declarative plotting API that follows your theme, a WYSIWYG markdown editor, and themes that save into the notebook file itself so the look travels with the file.
Start with CONTRIBUTING.md. Setup is npm install then npm run dev, with Node 20 or newer and no backend service to stand up.
For anything beyond a small fix, have a look at the open issues and open pull requests first, then open an issue describing what you have in mind. That gives you a chance to hear about related work, an architecture constraint, or a shorter path to the same result before you write a lot of code.
The coding conventions are written as reasons rather than as a list of rules, and they are worth reading that way. Nearly all of them exist to protect a handful of things. Fine-grained SolidJS reactivity, one clear owner for each kind of state, the Python and TypeScript sides of pynote_ui staying in agreement, notebooks staying portable .ipynb files that open elsewhere, and executed Python staying inside the worker sandbox.
AI-assisted contributions are welcome, and CONTRIBUTING.md has a section on what is expected. The short version is that you are the author and the reviewer of whatever you submit, whichever tools helped produce it, so read it, actually run the checks, and be able to explain it.
Thanks for being here.