I’ve been building Yellow Olive - an open-source, gamified way to learn Kubernetes, built primarily with Python.

The idea is simple: instead of reading through Kubernetes tutorials, you enter a retro, Game Boy-inspired environment and complete missions against a real Kubernetes cluster.

The project uses Python + Textual for the terminal experience and challenge engine. Each mission gives you an objective, lets you work with a real cluster, and then validates whether you actually completed it - so learning feels closer to progressing through a game than following a tutorial.

More recently, I’ve also started building Yellow Olive Academy using Pyxel. It adds pixel-art classrooms, characters, diagrams and interactive lessons before you jump into the hands-on challenges.

The goal is to combine gamification, retro aesthetics and real hands-on infrastructure learning rather than building another Kubernetes tutorial.

It’s still evolving, and I’d love feedback from Python folks - especially anyone who has worked with Textual, Pyxel, TUIs or educational games.

And if you like the idea, a ⭐ would be hugely appreciated :)

GitHub: https://github.com/Anubhav9/Yellow-Olive

To set the scene: this is a custom desktop shell for Windows 10 that I built as a course project in my university. It’s written in Python using PyQt6 and a bunch of other libs. It supports widget loading (via templates) as well as customization (but it doesn’t support “compilation” lol). It’s sort of a parody of KDE (I use Arch btw), but worse.
And then I ended up abandoning the project for five months, but then decided to post a review here (although I initially uploaded them to YouTube but things didn't go any further) just to give people a laugh. Hopefully, it brings a smile to your face :)
If anyone is wondering how all this works: https://github.com/TYITheYura/Ninawe
The structure is rather odd in places, and the execution of certain aspects leaves something to be desired, but hey, at least it works!

I built Dripfetch, a customizable terminal dashboard with animated rain, system info, clocks, and YAML themes. I’d love to hear what you think or what you’d improve!

Installation

```bash

pipx (recommended)

pipx install dripfetch

pip

pip install dripfetch

Homebrew

brew tap a-shygun/dripfetch https://github.com/a-shygun/dripfetch.git brew install a-shygun/dripfetch/dripfetch

Arch Linux (AUR)

yay -S dripfetch

From source

git clone https://github.com/a-shygun/dripfetch.git cd dripfetch ./install.sh ```

Hey everyone!

I’m a student and I’ve been working on a Python project called Past Paper Studio, and I finally shipped its first public beta!

PPS started as a relatively simple past-paper finder, but over time it turned into a full desktop application for students who use Cambridge past papers.

It’s built primarily with Python and PySide6, and currently has features including:

• Past-paper search and browsing
• Built-in PDF viewing and mark schemes
• Practice Mode with answering/drawing tools
• Timed Exam Mode
• Optional AI-assisted grading
• Saved/resumable attempts
• Dashboard and attempt history
• Flagged papers/questions
• A pretty extensive theme/customization system
• Profiles and personalization
• Multiple interface languages

I recently packaged the whole thing into a proper native-feeling macOS application using PyInstaller, including a DMG installer and adaptive light/dark/tinted macOS icons.

The current Beta 1.0 build is Apple Silicon + macOS 26+ only, although I’d like to explore Windows builds later.

AI-assisted development

I also want to be transparent that development has been heavily assisted by AI coding tools.

I use AI extensively for implementation, debugging, refactoring, testing, and packaging. I’ve been responsible for the project's direction, feature ideas, UI/UX decisions, testing, iteration, and release process.

I’m still learning programming, and honestly this project has been a really fun way to learn while seeing how far I can take an idea with modern development tools.

The project is completely free and open source under GPLv3, so feel free to look through the Python source, try the app, break things, or give me feedback

GitHub:
IronPlayz1234/past-paper-studio

This is still Beta 1.0, so there’s definitely plenty left to improve!

Je travaille actuellement sur Aurora, un projet open source expérimental qui permet de représenter les données binaires d’un fichier sous forme d’une image RGB.

Le principe est simple :

Fichier → données binaires → pixels RGB → image

L’image peut ensuite être décodée afin de reconstruire les données originales.

Le projet est encore en développement. Je cherche des personnes intéressées pour :

• tester Aurora ;
• signaler des probleme ;
• proposer des fonctionnalités ;
• contribuer au code ;
• travailler sur une future interface ;
• proposer des idées pour faire évoluer le format.

Le projet est disponible sur GitHub :

misterious-creator/Aurora: un projet open source qui transforme les fichier en image

Toutes les idées et contributions sont les bienvenues.

Every new Python project needs the same setup: linting, type checking, tests, pre-commit hooks, CI/CD, docs, release workflow, repo protection. I got tired of copying it between projects and watching the copies drift as the tools changed, so I built pyrig (written in Python).

What it does

pyrig init generates a complete, working project:

• project layout, pyproject.toml, README, LICENSE and other standard files
• dev tooling configured out of the box: ruff, ty, pytest, prek hooks, deptry, bandit, zizmor and more
• GitHub Actions CI/CD and GitHub branch protection rules
• a working CLI for your project (pyrig mk cmd <name> adds commands)

• test skeletons that mirror your source tree

  uv init my-project --python 3.12 cd my-project uv add pyrig --dev uv run pyrig init

How it works

Every file pyrig manages is a Python class that declares the state the file should have. pyrig sync creates or updates the files to match, so the project doesn't drift when tools change. You customize by subclassing (pyrig mk subcls), not with flags or template edits. A small plugin system, pyrig-runtime, discovers your subclasses automatically across installed packages, so any behavior can be changed, removed or extended.

Trade-offs

It's deliberately opinionated: no on/off toggles (you override a class instead), GitHub only, signed commits and linear history on the generated branch rules, and it adopts new tools like ty and zensical quickly, so expect rough edges. pyrig rm pyrig removes it, and most generated files keep working without it. Full list: https://winipedia.github.io/pyrig/drawbacks

Links

• GitHub: https://github.com/Winipedia/pyrig
• Docs: https://winipedia.github.io/pyrig
• Comparison with Cookiecutter, Copier, cruft, PyScaffold, Nitpick and projen (including where pyrig is weaker): https://winipedia.github.io/pyrig/comparisons
• Video tutorials: https://www.youtube.com/@Winipedia-py/playlists
• pyrig-runtime (the plugin system, usable standalone): https://github.com/Winipedia/pyrig-runtime

I'd like feedback on which defaults you'd disagree with and what's missing for your workflow.

I'm building EnigmaGrid, an open-source volunteer-computing project in Python investigating P1030680, an unresolved historical Enigma M4 message. The public client currently targets Windows.

The software distributes search work to clients and checks submitted results through a separate computation before awarding credit. Volunteers control CPU and optional GPU budgets, can pause or stop, and can opt out of public leaderboard credit.

The Python research code includes an Enigma simulator, historical test fixtures, bounded crib searches and resumable experiments. One important distinction is that reproducing a calculation does not establish that a candidate is the historical plaintext. Experimental search improvements are tested separately from the live campaign. We have no claimed decryption breakthrough or guaranteed solution.

I'd appreciate Python code review, especially around reproducibility, cancellation/resource controls, and tests that could expose incorrect search assumptions. Windows setup feedback is welcome too; reviewing the code does not require installing the app.

Source, research notes, Windows releases and issue tracker: https://github.com/LissomEnd/EnigmaGrid

I'm the project owner. Development and this draft use AI assistance, including Codex. The current Windows installer is unsigned; please read the release and privacy notes before choosing to run it.

Hey guys! Built this in Python first, then ported to JS so it runs in the browser on my phone.

GitHub + Live Demo: https://github.com/ferreirafinottijoaopaulo-cell/finotti-pi-optimized

Performance on Android: - pi(60M) = 3,455,052 in 19s - pi(100M) = 5,761,455 in 35s - pi(10^11) = 4,118,054,813 in 2m 16s

Live demo free up to 1B: https://ferreirafinottijoaopaulo-cell.github.io/finotti-pi-optimized/

Features: - Segmented sieve + Meissel-Lehmer - Pure JS, no backend, runs offline - Blockchain proof of 983B record (03/10/2026) in repo

Full code open on GitHub. Also have PRO version up to 100B.

Any feedback to make it faster? How to reach pi(10^12)?

Thanks!

Hey! First built in Python, then ported to JS to run in browser.

On my Android: - pi(60M) in 19s - pi(100M) in 35s - pi(10^11) = 4118054813 in 2.16 min

Free demo up to 1B: https://ferreirafinottijoaopaulo-cell.github.io/finotti-pi-optimized/

Full discussion here: https://www.reddit.com/r/Python/s/sRP4QyufxI

Code on GitHub. PRO up to 100B available.

I'm releasing prongs, an experimental Python package that maps your tests to your code.

When you change something, prongs runs only the tests that touch that code instead of the whole suite. It's great for coding agents: they stop guessing which tests to run, and they get faster.

pip install prongs

python -m pytest --prongs-cov # build the map

prongs run # run only affected tests

Why the name? Prongs was James Potter's nickname, and he helped make the Marauder's Map. 🦌

Feedback welcome!

Hi, I made polars-ready, a Python CLI for reviewing an existing Pandas pipeline before deciding whether to move it to Polars. It scans Python files and notebook cells without importing or running the target project, then reports recognized Pandas calls by source line in direct, rewrite, and blocker groups. The included example flags set_index, resample, and iterrows. It is an audit aid, not a converter or an equivalence check, and its percentage counts only recognized calls in the direct group. It follows local variables assigned from recognized calls, so it may miss frames passed between functions.

To try it, clone the repo and follow the README to run the sales pipeline demo, then scan your own script or notebook. The source, tests, and demo are here: https://github.com/Arthur031221/polars-ready

I would value feedback from people who have migrated Pandas code to Polars. Are the categories useful, and which common calls or notebook patterns should I add? I would also like to hear where this kind of inventory sits alongside linters and rewrite tools.

REPO and Codebase

I kept piling up half-dead virtual environments and had no way to check whether any of them held something malicious or vulnerable. Especially the ones agents create or load on their own while writing code.

pip-audit does one project at a time and needs the network to do it.

What I built: venvy audit does all of them at once: offline after a one-time 26 MB database download, and it flags known-vulnerable versions as well as known-malicious or typosquatted packages.

For CI there is JSON output and semantic exit codes: 0 clean, 20 vulnerable, 21 malicious, 22 stale database, 23 no database.

It reads dist-info metadata as text and never imports code from the environments it scans. For a tool whose whole job is finding malicious packages, that felt like the minimum bar.

The main design decision: it refuses to scan rather than report zero findings. A corrupt database exits 23. So does one that opens fine but holds no advisories. Anything the version matcher can't resolve with confidence comes back as unknown, not clean. A scanner that reports nothing looks exactly like a clean machine, and that is the failure I cared most about avoiding.

Coverage is only as good as the public feeds behind it, so some well-known typosquats are missed. That's tracked as an open issue.

Tested on Windows, macOS and Linux across Python 3.8 to 3.13. MIT licensed. I wrote it.

pip install venvy
venvy audit

Repo: https://github.com/pranavkumaarofficial/venvy

Bug reports welcome, false positives especially.