live-de-python: a weekly Python live-coding show kept in the open by its community
Repositório das lives de python semanais
At a glance
- What is it?
- live-de-python is a Brazilian weekly Python live-coding project that publishes the slides and the code from every session in a public repository, run by volunteers and funded by recurring donations. The judgement is that the archive, not the stream, is the durable asset, and that a reader who does not speak Portuguese gets the code without the explanation.
- Who is it for?
- live-de-python fits a Python developer who learns better by watching someone build a project than by reading a tutorial, and who wants an archive that can be searched and cloned rather than only streamed. It does not fit a reader who needs English-language commentary, since the slides, the repository documentation and the community channels are in Brazilian Portuguese, and it does not fit a team looking for a maintained library, because nothing here is a library.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 127 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 6, 2026, and from our analysis. They are not legal advice.
Star history
- dunossauro/live-de-python1,305 ★ · +0
| Repository | 2026-10-20 | 2026-11-06 |
|---|---|---|
| dunossauro/live-de-python | 1.3k | 1.3k |
0 Stars in the last 17 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
A stream that publishes its own source material
live-de-python is an independent project created by dunossauro to spread knowledge of the Python language in an open and free way. The sessions happen every Monday at 22:00 on the project's YouTube channel, and the project also lists Twitch among the places to find it.
The distinctive choice is what happens to the material afterwards. The repository holds the slides and the code discussed during the live sessions, and the documentation points to two places for them. The `codigo/` directory has the source code of the projects created during the sessions, with its own `README.md` acting as the index of past sessions. The `slides/` directory has the explanatory slides from previous sessions.
So this is not a channel that publishes a video and disappears. Every session leaves behind a directory of working code and a document explaining the topic, and both are in the same repository, under the same licence, reachable without an account and without a video player.
The `stuff/` directory sits alongside them at the root, and there is a `.github/` directory and a `.gitattributes` file for the repository mechanics. The top-level entries are small in number, which is what you would expect from a repository whose content is organised by session rather than by module:
The whole project is MIT licensed with a `LICENSE` file at the root, so the code and slides can be reused, remixed and taught from. That is a licensing observation rather than legal advice, and the `LICENSE` file governs.
Past sessions live in one index, future ones live in issues
The documentation describes the two halves of the schedule with two different mechanisms, and the split is a deliberate piece of project design.
Past sessions are reachable through the `codigo/README.md` file, which is the archive index. A new reader arrives at a single document listing what has been built, and each entry leads to the code for that session. Nothing about the format of a past session is described in detail in the project documentation, so the index itself is the thing to read.
Future sessions are reachable through the issues tracker, with the documentation pointing at issue 568 as the place to look for upcoming sessions. The same mechanism doubles as the suggestion channel: to propose a topic for an upcoming session, you open an issue.
That is a neat bit of project hygiene. The issue tracker is not a support queue, it is the programme schedule, which means the public record of what the project intends to cover is the same place where the community proposes it. A reader can see both the backlog and the proposals in one place, and a proposer can see whether their topic is already on the list before writing.
The project also lists several community channels beyond the video: a Telegram group, which the documentation describes as the place where people talk about the sessions and Python in general, plus presence on YouTube, Twitch and Twitter. The Telegram link in the documentation has a small typo in the URL prefix, which is worth knowing before you try to open it.
The project has no GitHub releases, which is expected for a repository of this kind since the content is versioned by commit and organised by session date rather than by release tag.
Funding is recurring, and the numbers are stated
The project describes itself as maintained by volunteers in a crowdfunding campaign, and the funding section is unusually specific for a project of this kind, which is a good sign about how seriously the organisers take it.
The primary channel is Apoia.se, described as the recurring financing used for the longest time, with the note that 13 percent of the value stays with the platform. The Patreon account is for recurring financing from people outside Brazil, which is a sensible split given that payment logistics differ by country.
The documentation then explains the word recurring in plain terms, which tells you the intended mental model: you can donate 5 reais every month, and that guarantees the project stays alive and active for longer, which in turn allows financial planning. A fixed monthly amount is what makes a small project schedulable.
There are also non-recurring options. PicPay accepts a one-off donation of any amount with no recurrence commitment, and Pix is available by email at `[email protected]` or through a random key `5363bcfa-aacd-4a87-84c3-917305af4a65`.
The distinction between recurring and one-off is the whole point of the section, and it is the clearest statement of the project's dependency: the sessions continue as long as enough people commit to a small recurring amount.
What a newcomer actually gets, and the language barrier
There is a real limitation here and it is not a technical one. The project documentation, the slides and the community channels are all in Brazilian Portuguese, and the project is explicitly Brazilian in identity, with the country named in the repository's topic list and separate funding arrangements for people inside and outside Brazil.
That is not a criticism so much as a fact to plan around. The code is universal and MIT licensed, so a developer who reads Python can read the source files in `codigo/` and learn from them directly, whether or not they follow the prose. The slides carry the explanation, and those need Portuguese or a translation. The Telegram discussion, where questions are asked and answered, is in Portuguese too.
The practical structure of the archive is what makes this workable. Each session that built a project leaves that project's code in its own place, and the `codigo/README.md` index is the map. Someone who wants to know how a particular problem was solved in Python can browse the index, open the relevant folder, and read working code rather than a transcript.
The other limitation is about the passage of time. The sessions are weekly, which means the archive spans a long period of Python versions, and the project documentation does not describe a shared environment, a pinned requirements file, or a compatibility policy for the older sessions. The `slides/` directory follows the same session-by-session structure, so the version that a given code sample targets is something you find out by looking at that session's material rather than from a project-wide statement.
Volunteer-run, and the maintenance signal it sends
The last push to the repository was on 2026-07-03, and the repository is not archived. Between those two facts and the weekly cadence of the sessions, the project reads as one that is still running.
The nature of the content is what makes the maintenance question unusual. A software library that goes three months without a commit is a liability, because something has broken and nobody fixed it. A repository of teaching material that goes three months without a commit is a paused archive, and the material it already holds does not decay in the way a library does. The code in `codigo/` still runs, and the slides still explain.
That said, the project is explicitly volunteer maintained and dependent on recurring donations, so the honest description is that it depends on a small number of people continuing to show up on Monday evenings, and on enough of the audience continuing to pay five reais a month. The documentation itself frames continuity in exactly those terms.
What a new volunteer inherits is a well-organised repository with a clear division between code, slides and community, a documented funding process with several payment methods, and an issues tracker that doubles as the schedule. The barrier to contributing is not technical, it is finding a topic that is not already covered and writing it up in a way that fits the existing structure.
The channel list, with Telegram for discussion, YouTube and Twitch for the live sessions and Twitter for announcements, is the coordination surface. There is no separate wiki, no issue templates and no contributor documentation beyond the README, so a prospective contributor learns the conventions by looking at what is already there.
Editorial conclusion
live-de-python fits a Python developer who learns better by watching someone build a project than by reading a tutorial, and who wants an archive that can be searched and cloned rather than only streamed. It does not fit a reader who needs English-language commentary, since the slides, the repository documentation and the community channels are in Brazilian Portuguese, and it does not fit a team looking for a maintained library, because nothing here is a library. Verify first that the code in `codigo/` runs against the Python version you use, since the sessions span a long period, that the environment each session expects is described in that session's own folder rather than in a shared requirements file, and that the topic you want covered has not already been covered by checking the archive in `codigo/README.md` before opening an issue.
Frequently asked questions
What is live-de-python and when do the sessions happen?
It is an independent project created by dunossauro to spread knowledge of Python in an open and free way. The live sessions happen every Monday at 22:00 on the YouTube channel, and the project also lists Twitch among the places to find it.
Where can I find the code and slides from past live-de-python sessions?
The source code of the projects built during the sessions is in the `codigo/` directory, with the index of past sessions in `codigo/README.md`. The explanatory slides from previous sessions are in the `slides/` directory.
How do I suggest a topic for a future live-de-python session?
Open an issue in the repository. The documentation points at issue 568 as the place to see upcoming sessions, so it is worth checking the schedule and the archive first to see whether the topic is already planned or already covered.
How is live-de-python funded?
Through recurring donations, primarily on Apoia.se, where the documentation notes that 13 percent of the value goes to the platform, and on Patreon for supporters outside Brazil. One-off contributions are possible through PicPay or Pix.
Can I reuse the code and slides from live-de-python?
The repository is MIT licensed, with the `LICENSE` file at the root, so the code and the slides can be reused, modified and redistributed under those terms.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/dunossauro-live-de-python)Star history chart for your README
[](https://hysenlabs.com/projects/dunossauro-live-de-python)Was this useful?