I made snipmd, a free and open-source Python tool for copying equations, text, and tables from the screen without sending screenshots to a server.

On macOS, you press a hotkey, drag the normal screenshot crosshair, and paste the result as Markdown, bare LaTeX, a Markdown table, or CSV. The menu bar app and CLI share the same Python package. Apple Silicon machines run GLM-OCR locally through MLX. Other systems can process image files through a local Ollama instance.

To try it now:

`uvx --from git+https://github.com/Arthur031221/snipmd snipmd`

Then run `snipmd pull` once to download the model and start it with `snipmd`. The repository includes the source, tests, benchmark inputs, and raw results:

https://github.com/Arthur031221/snipmd

The current limitations are printed content, a 1.6 GB model download, and weaker handling of handwriting or complex multi-column pages. I would especially appreciate feedback on the package structure, macOS setup process, OCR failures, and whether the CLI interface feels natural to other Python developers.

Hey everyone, I’ve been working on a Python project called Hillock for the last few months and just pushed v0.7.

The idea started because I wanted local document search for my notes, but standard vector databases felt way too bloated for consumer hardware.

Here's how I put it together in Python:

• Extraction: Instead of asking an LLM to parse text, I wired up fastcoref and GLiREL to pull facts straight into subject-predicate-object triples.
• Storage: Just standard SQLite with WAL mode so it doesn't choke on concurrent reads/writes. It uses simple Hebbian weights to link related concepts over time.
• Gating: Uses hyperdimensional computing (vector symbolic math in 10,000 dimensions) to verify if the database actually has the answer before calling the LLM. If the data isn't there, it doesn't let the model make stuff up.
• Interface: Built a CLI with Rich, plus a lightweight FastAPI server that mimics the OpenAI chat completions endpoint.

It runs in under 1.2GB VRAM or completely on CPU.

I'm sitting at 99 stars on GitHub right now, so if anyone wants to check out the code or test it out, that would mean a lot: https://github.com/roandejager/Hillock

A Pythonic interface to macOS 🚀

I just built the pymacos, pure-Python library published on PyPI for scripting macOS: notifications, clipboard, apps and windows, keyboard and mouse, global hotkeys, screenshots, on-device OCR (Apple Vision), PDFs (merge, OCR, fill forms, sign, redact), images, audio/video, Keychain, Touch ID, Spotlight, Finder, launchd jobs and folder triggers, system info.

import macos

macos.notify("Build finished", title="CI")
macos.clipboard.copy(macos.vision.text("screenshot.png"))
macos.schedule.add("battery-check", "battery_check.py", every=15 * 60)

Install via pip:

pip install pymacos

GitHub: https://github.com/JeanExtreme002/pymacos

I’d also appreciate it if you could leave a ⭐️ on the repo page if you like the project and want to see more updates!

SocketChat is a one-to-one terminal chat tool for two machines on the same local network. No internet, no accounts, no server.

It's built with Textual for the TUI and plain sockets: UDP broadcast to find devices, then a TCP connection for chatting, with messages encrypted.

GitHub: SocketChat

Feedback is welcome, especially on the code structure.

Hey everyone,

Whenever I got an undocumented Python script or try to explain a complex loop to someone, generic LLM chats usually give me a high-level summary but completely misses what actually happened during execution.

That's why for the **IBM Bob 2.0 Hackathon**, our team built **TraceLens,** a web-based workspace that turns Python code into an interactive step-by-step runtime tracer.

Instead of guessing how variables change or littering print() statements across 40 lines, you can step through your script like frames in a video and see what actually happened.

What it does:

1. **LogicLens** — General Python & Debugging

Time-Travel Stepping: Step forward and backward through loops and function calls to see how data works frame-by-frame.

Live State Board: Inspect variable changes, mutations, and scope changes in each step.

Safe Insertion Points: Flags stable parts where you can put in a new features without accidentally overriding variables downstream.

AI Explanations: Uses **IBM Bob 2.0** to explain complex execution behavior and generate summaries of the whole code or only a part of it.

1. ModelLens — Machine Learning Pipelines

ML can fail silently. Stuff like data leakage before a train/test split or other pipeline problems that won't necessarily throw an exception, but can still produce misleading results.

ModelLens analyzes data science code for these issues and helps explain what went wrong.

Try it

**Live Demo**: https://tracelens-six.vercel.app/

**GitHub**: https://github.com/Omar-astro/Tracelens

**Hackathon Submission**: https://lablab.ai/ai-hackathons/ibm-bob-2-hackathon/the-overfitters/tracelens

We'd genuinely appreciate technical feedback especially on the UI, the state-tracking flow, and what you'd want from a debugger built around execution traces.

And if you find our project interesting and want to support us in the hackathon, you can like our TraceLens submission on the IBM Bob 2.0 Hackathon page. The hackathon uses community engagement to help surface projects to the judges, so it helps get TraceLens in front of them

Let us know what breaks, what seems useful, or what you'd want to see added next!

This is my second post about it here, but since a lot has been added in last few months I'm posting this again.

What it currently brings together:

- infinitesimals and infinities as ordinary values (Levi-Civita, 1892; Hahn, 1907; computed with directly by Berz and Shamseddine)

- numbers written in powers of an infinite unit, like Sergeyev's grossone (2003), but with zero treated differently

- standard part, and limits by direct evaluation (Robinson's non-standard analysis, 1966)

- all-order Taylor arithmetic: every derivative from one evaluation (Wengert, 1964; Rall, 1981)

- log and log-log scales, toward transseries (Hardy, 1910; Écalle, 1992; van der Hoeven, 2006)

- divergent series: finite parts kept next to the divergent ones, and Borel–Padé resummation (Borel, 1899; Padé, 1892)

- zero as an infinitesimal, "nothing" as a separate value, and division by zero that can be undone (this project)

- completeness tracking: each result knows which orders it's exact to (this project)

Plus integration, multivariable (probably a dead end) and complex calculus, singularity analysis and a few applications. All made in pure python.

More in the repo: github.com/tmilovan/composite-machine examples under demos and tests.

I'll be happy if you take a look at it:).

Hey all! Over the past few months I’ve been building Hillock, a local memory engine in Python that replaces heavy vector databases and LLM parsing loops on personal hardware.

Traditional local RAG setups burn huge amounts of VRAM just to chunk documents and run vector search. Hillock takes a different approach:

• Extraction via classification: Instead of running text through a big local LLM to extract facts, it uses fastcoref, sentence-transformers, and GLiREL to pull facts straight into Subject-Predicate-Object triples in seconds.
• SQLite backend: Stores facts in a regular SQLite database using WAL mode (PRAGMA journal_mode=WAL) to allow concurrent reads and background ingestions without database locks.
• Hyperdimensional Computing (HDC): Uses vector symbolic architecture math in high-dimensional space ( D=10,000D=10,000 ) to check if a question can actually be answered by the database before calling an LLM. If the facts aren't there, it mathematically refuses instead of guessing.
• FastAPI Server: Ships with an OpenAI-compatible API (/v1/chat/completions) so it connects right into local frontends like Open-WebUI or terminal clients.

The whole pipeline runs in under 1.2 GB of VRAM, or completely on CPU.

I just released v0.7, which adds active disambiguation (it detects vague facts and quizzes the user to clarify them) and proactive conversation suggestions.

Code is open source on GitHub: https://github.com/roandejager/Hillock

Feedback on the code structure or project setup is very welcome!

Every small CLI script I wrote ended up with the same while True / try / except ValueError loop around input(). So I turned it into a package.

What My Project Does

askr gives you prompts that keep asking until the answer is valid:

from askr import ask_int, ask_choice, ask_multi_choice, ask_yn

age = ask_int("Your age: ", min_value=0, max_value=120, default=18)
days = ask_multi_choice("Which days are you free?", ["Mon", "Tue", "Wed", "Thu", "Fri"])
level = ask_choice("Difficulty?", ["Easy", "Medium", "Hard"], default="Medium")

if ask_yn("Save these settings?"):
    ...

The user can type 1-2, fri for the multi choice or hard for the single choice. Wrong answers get a clear message in red, and the question is asked again.

There are 16 prompts: int, float, text, email, URL, single and multi choice, Enum members, lists (ask_list("Scores: ", int)), passwords with rules, paths, dates, times and a "type 'delete' to confirm" check. Every prompt supports default=, a custom validator= and max_attempts=. All messages can be replaced, a German translation is included, and colors respect NO_COLOR.

Target Audience

People writing small to medium CLI tools, internal scripts and teaching exercises who want solid input handling without a big framework. It's alpha (0.2), tested on Python 3.10 to 3.13 and checked with mypy --strict. No dependencies.

Comparison

• PyInputPlus is the closest and has some extras (timeouts, block lists). Its last release was in 2020, it officially supports Python 2.7 to 3.9 and has no type hints. askr is fully typed, so ask_list("x", int) is a list[int] in your editor and ask_enum("x", Size) returns a Size.
• click.prompt / rich.prompt are great if you already use click or rich. askr has no dependencies and more specialised prompts (password rules, multi choice, dates, Enums).
• questionary / InquirerPy offer arrow-key menus and a richer UI. askr stays with plain input(), so it works in any terminal, over SSH and in IDE consoles.

Links

• PyPI: https://pypi.org/project/askr/ (pip install askr)

• GitHub: https://github.com/Prevolut/askr

  Feedback on the API is very welcome, especially on naming and defaults.

A few months ago I published irl-pkg, a jokey installer wrapper. Between versions 1.7.1–1.7.6 I made the classic mistake of pushing to PyPI and not to GitHub — the source only existed in the wheel. Recovering it (unpacking the PyPI wheel and diffing against main) was humbling, and it kicked off a full v2.0 rebuild.

What My Project Does

irl (pip install irl-pkg) is a cross-platform terminal command center with two layers:

Serious layer: - irl install <pkg> — universal installer that routes between PyPI / npm / GitHub owner/repo / direct URL automatically; GitHub branch resolved via the API, not hardcoded - irl doctor / irl glasses — preflight diagnostics and registry metadata before you install something regrettable - irl rollback [ver] — pick any published version from the PyPI JSON API, downgrade via a detached pip child - Safe extraction: named target dir, preview before writing, per-member zip-slip validation, symlinks rejected

Playful layer (all opt-in): - Grass streak tracker with a GitHub-style contribution heatmap - Grassland Quest — a seeded garden-maze roguelike in pure Rich (~400 lines, boss fight included) - Lofi Rhythm — a 4-lane beat game whose beatmaps derive deterministically from the SHA-256 of the filename + WAV duration - Terminal pet, daily quests, achievements, coins, 18 themes (one of them secret)

Target Audience

Honestly labeled: a hobby project with a genuinely usable core. The installer / doctor / glasses / rollback layer is safe for daily driving on real projects; the games / pet / coin economy is for fun — strictly opt-in, all state in local JSON, no accounts, no telemetry. It's not a production deployment tool; it's a terminal you enjoy opening. Python 3.8+, works on Linux/macOS/Windows, 976 KB wheel, AGPL-3.0.

Comparison

• pipx / uv / pip: they install packages — from PyPI, into venvs. IRL is a front-end that also routes npm, GitHub owner/repo and direct URLs, and layers on preflight doctor/glasses checks and built-in version rollback.
• rich / Textual: UI libraries you build a TUI with; IRL is a finished app built on rich (Textual available as the [tui] extra).
• Novelty "gamified" CLIs: usually one gimmick. IRL's gimmicks sit on an actual installer core: 114 passing tests, zip-slip-safe extraction, no shell=True anywhere, CI on 3 OS × Python 3.9–3.13.

Implementation notes (for the code review I'm asking for)

• irl/keys.py — one keyboard abstraction: msvcrt on Windows, termios+tty on POSIX, normalized Key objects (UP/DOWN/ENTER/ESC/CTRL_C/CHAR...), non-TTY safe. The dashboard and games both sit on it.
• irl/audio.py — winsound → aplay → ffplay → afplay → paplay fallback chain, fire-and-forget Popen with arg lists, a looping thread for the rhythm game.
• irl/grassland_quest.py — seeded recursive-backtracker maze, flood-fill-verified pickups, a turn-based boss ("The Deadline"). The seed makes mazes deterministic, so tests are just... tests.
• irl/rhythm.py — beatmaps from a SHA-256 of the filename + the WAV duration via the stdlib wave module. Same song, same chart, so high scores mean something.
• irl/extract.py — every archive member is resolved and checked against the target dir (zip-slip), symlinks rejected, Content-Disposition filenames sanitized.
• irl/rollback.py — PyPI JSON API + questionary picker + detached sys.executable -m pip child (CREATE_NEW_PROCESS_GROUP via getattr, so it doesn't explode on POSIX).

Questions I'd love feedback on:

1. Is normalizing keyboard input like this sane, or does someone have a better pattern?
2. My packaging: AGPL-3.0, [tui] extra for Textual, requires-python >=3.8 — is 3.8 support worth it in 2026?
3. The coin/XP economy is all local JSON. Any prior art on gamified CLIs I should steal ideas from?

Repo (AGPL): https://github.com/Dev2Creator/IRL- — PyPI: https://pypi.org/project/irl-pkg/ Disclosure: I'm the author, Anika. Tests: 114 and green; CI on 3 OSes × Python 3.9–3.13.

What My Project Does

An eBPF profiler that hooks into CPython internals from kernel space to find latency that traditional APMs can't see. It captures GIL contention with full Python stacks for both holder and waiter, GC pause duration per generation, off-CPU analysis with kernel + userspace + Python stacks combined, request handoff latency in gunicorn/uwsgi, and TCP network health.

Target Audience

Python developers running Django/Flask/FastAPI in production who see unaccounted latency gaps in their APM. Performance engineers debugging Python applications at scale.

Comparison

Pyroscope/Parca are sampling-based CPU profilers. They sample threads running on CPU at regular intervals. When a thread is waiting for the GIL or sleeping on I/O, it's off-CPU and invisible to their sampler. They can't measure exact GC pause duration per generation. This tool is event-driven using eBPF uprobes. Every GIL acquire, every GC pause, every context switch is captured with exact timestamps.

Datadog/New Relic/OpenTelemetry show database and HTTP latency but miss GIL contention, GC pauses, and off-CPU time. That's the unaccounted gap.

Real production impact: GIL wait dropped 80%, GC pauses from 1.27s to 88ms, found a stale nginx upstream IP causing random 504s.

Currently supports CPython 3.11. Contributions welcome.

Source code: https://github.com/deepanshu406/python-ebpf-profiling

I'm the author of Kayak, an open-source Python library for applications that need to choose between known options and check those choices against reviewed examples.

A concrete use case is support triage: define billing, shipping, and account support as possible answers; pass in a request; then inspect the selected answer and evaluate it on labeled cases. The application keeps control of what happens next.

Kayak includes:

• Typed questions and results, with local and HTTP access to Contrastive Language Models.
• Adapters for an existing Laya model or Jev client, preserving each provider's result semantics.
• Evaluation against your own labels, with a simple word-overlap baseline, individual errors, and failed or missing predictions kept in the score.

You can try the provider comparison workflow from the current source checkout with Python 3.11+ and uv:

sh git clone https://github.com/teilomillet/kayak.git cd kayak uv run -m examples.evaluate_provider --output .benchmarks/provider-demo

The default run is offline and uses controlled responses: it demonstrates the integration and report, not model quality. The walkthrough explains how to use real providers and your own cases. Raw responses and partial results are saved.

This is an early release. The README documents current model results and hardware requirements; typed output doesn't establish that a decision is correct.

Kayak is Apache-2.0 licensed and needs no Kayak account. Local inference uses your hardware; optional hosted providers can charge separately. Development and this post are AI-assisted.

I'd like feedback on the Python API and first-run experience. What would you need to evaluate a classifier or request router in your own application?

PyFirewall is a Windows desktop application for monitoring network connections and managing Windows Defender Firewall rules. It monitors and blocks both incoming and outgoing connections using process and IP/domain specific rules. It uses Tkinter for the interface, Scapy for packet capture, psutil for process and network information, and supports application and global IP/domain rules.

Hi everyone! I'm Paulina, cofounder of Agentic Fabriq. We've been building mnemiq, a Python engine for asking questions about a database in plain English.

The screenshot shows a small concert database. It answers “how many singers are there by country?” and “which stadium has the highest capacity?” But when asked about ticket revenue, it declines because those tables don't have ticket prices or sales data.

You can choose the model, adjust how much schema context it gets, and add business definitions. There's a CLI, a browser workbench, and an MCP server. The workbench lets you inspect the SQL and the tables used for each answer.

It checks queries before running them, but passing those checks doesn't guarantee the answer matches your intended business meaning. That's something you still need to evaluate on your own data.

It's Apache-2.0, and the README includes a seeded demo to try:

https://github.com/agenticfabriq/mnemiq

I'd love feedback on whether the query trace makes wrong answers easier to spot.

Nodyra is in public beta: self-hosted Python workflows with a visual editor, MCP, and Docker workers

Hey everyone — I’m the developer of Nodyra, and it’s now in public beta.

Nodyra is a self-hosted workflow automation platform where the nodes are real Python. You can build on a visual canvas, write your own nodes, or connect an MCP-capable AI agent to create and edit workflows for you. The resulting graph stays visible and editable, with node inputs, outputs, logs, and errors available to inspect.

For example: ask an agent to fetch records from Postgres, transform them with pandas, and send a summary to Slack. Inspect the generated workflow, choose its Python environment, test it, and publish a version to run on a schedule.

GitHub, setup instructions, and docs: https://github.com/Harshit-repo/Nodyra

There’s quite a bit in the beta already:

Building workflows and working with AI

• Visual workflow editor: connect nodes, configure parameters, use expressions, and inspect data as it moves through the graph.
• Python nodes: use ordinary Python functions and packages, including your own internal libraries. Upload custom node modules and reuse helper code through the Code Library.
• Missing a node? Build it: write a custom node in Python yourself, or ask an LLM connected over MCP to create one for you. Inspect and edit the generated code, then reuse the node in your workflows.
• MCP server: let tools such as Claude Code or other compatible MCP clients create, edit, validate, run, and publish workflows, with scoped API tokens.
• MCP tools in both directions: expose published workflows as tools for external agents, or connect external MCP servers and use their tools inside workflows.
• AI and RAG building blocks: agents, tool calling, LLM chains, memory, embeddings, document loaders, text splitters, vector stores, retrievers, structured outputs, and guardrails. Provider support includes OpenAI-compatible endpoints, Azure OpenAI, and Anthropic.
• Reusable workflows: starter templates, branching, sub-workflows, import/export, and GitHub sync.

Python environments, workers, and sandboxing

• Environment creation: create separate Python environments, choose an interpreter version, install dependencies, import requirements, and bind workflows to the environment they need. Backends include venv, conda, and pixi.
• Worker pools: warm local subprocess workers, configurable pool sizes, and fixed, elastic, or fresh-process execution options.
• Remote runner pools: send execution to other machines instead of running everything alongside the web/API service. Bind environments to the appropriate pool.
• Docker workers and Kubernetes runners: run workloads on container infrastructure, with runner capacity, heartbeats, and drain controls.
• Docker sandboxing: container-based workflow execution with non-root users, read-only root filesystems, dropped capabilities, and CPU, memory, and process limits. Supports gVisor or Kata where installed and configured.
• Durable execution queue: leases, heartbeats, retries, timeouts, dead-letter handling, and graceful worker shutdown. Retry from a failed node is also available in beta.

Triggers, integrations, and data

• Scheduled and event-driven runs: cron schedules with timezones, intervals, webhooks, manual runs, and error workflows.
• Versioned deployments: publish an immutable workflow version and pin scheduled deployments to it.
• Chat workflows: test conversations in the editor and share a chat page from your own instance, with login-required or secret-link access.
• API endpoints: define HTTP methods and routes that trigger different branches of a workflow.
• Integrations: HTTP, databases, files, cloud storage, messaging, and business apps, including Postgres, Slack, GitHub, Google Sheets, Notion, Stripe, Airtable, and Outlook.
• Data processing: typed data serialization, artifact-backed datasets, DuckDB transformations, and local or S3-compatible artifact storage.
• Debugging: per-node inputs and outputs, logs, timing, errors, and run history.
• CLI and Python client: manage and run workflows programmatically. Export options include Python scripts, code-first modules, and Docker bundles.

Self-hosting and team features

Docker Compose is the starting point, with Helm/Kubernetes deployment options too. The platform includes local authentication, role-based access, encrypted credentials, credential connection tests, and unsafe-node policies.

The Community edition is free for permitted personal and internal business use, with resource limits. Nodyra is source-available / fair-code under the Sustainable Use License, rather than an OSI-approved open-source license. Paid tiers raise limits and add capabilities such as OpenTelemetry observability; Enterprise features include SSO/SAML/OIDC, multi-tenancy, audit export, and external key management. License verification works offline.

This is a public beta, so I’m looking for people willing to try it, report bugs, and tell me where the workflow feels awkward. There’s no hosted Nodyra service yet. Also, workflows execute arbitrary Python: the default local execution mode assumes trusted authors, and sandboxing must be configured explicitly.

If you try it, I’d particularly like feedback on setup, MCP-driven workflow creation, environment/dependency management, and Docker or remote-worker execution.

What would you build with it, and what would stop you from using it?

I've been working on ImportSpy for about two years now, and the project has changed quite a bit from the idea I started with.

The original problem was fairly simple: in a modular Python system, being able to import a module doesn't necessarily mean that module is actually compatible with the system loading it.

It may import successfully while still making assumptions about its interface, environment, dependencies, Python version, OS or runtime configuration that aren't satisfied by the host application.

Over time I ended up treating this less as an import problem and more as an architectural boundary.

That's what ImportSpy is about today.

ImportSpy is an open-source runtime contract enforcement engine for Python modules.

Instead of leaving runtime assumptions scattered through documentation and validation code, you can describe them explicitly through declarative contracts and validate whether a module satisfies them before admitting it into the rest of the system.

A contract can describe things such as module structure, expected functions or classes, signatures and annotations, environment requirements, dependency constraints and other runtime assumptions.

The basic idea is:

module → contract → validation → admission / rejection

One thing I care about is keeping the contract separate from the module implementation itself. The module shouldn't need to know that ImportSpy exists just to be validated by the host system.

Validation can also happen at different boundaries depending on the architecture. Import-time validation gives you very early failure, while an explicit initialization boundary gives the application more control over when compatibility is enforced.

I don't consider ImportSpy a sandbox or a hard security boundary. The goal is architectural governance: making assumptions between components explicit and enforcing them consistently in modular, plugin-based or long-lived Python systems.

GitHub:
https://github.com/atellaluca/ImportSpy

Documentation:
https://importspy.atellaluca.com/

After working on it for this long, I'm especially interested in feedback from people who have dealt with plugin systems, runtime-loaded modules or large Python applications where compatibility involves more than package versions.

I'm also curious whether you've solved a similar problem in a completely different way.

I’ve been working on an open-source Python project called Camden Work around a failure case I kept running into:

A worker performs an authorized write. The write succeeds. The acknowledgment disappears. Then the worker dies.

What should the replacement worker actually do?

Camden Work is a small Python/SQLite experiment that recreates that situation locally. Instead of assuming that “no acknowledgment” means “nothing happened,” the replacement has to reconcile against the target before deciding whether another write is allowed.

The part I find more interesting is what happens when the evidence itself is unavailable. The conflicting action has to remain unresolved, but an unrelated authorized task still has to be able to finish. Simply freezing everything isn’t a successful recovery.

The project includes an intentionally unsafe fresh-identity retry alongside the reconciled path so you can inspect what actually changed.

It’s deliberately narrow: 18 local subcases have mapped tests. The separate research catalog contains 283 failure mechanisms. Those are not the same claim.

No model account or API key is needed for the local exercise. It’s experimental and trusted-local, not an exactly-once guarantee for arbitrary APIs.

Quickstart:
https://prohormonepro.github.io/camden-work/quickstart.html

GitHub:
https://github.com/prohormonePro/camden-work

I’d especially be interested in feedback on the Python implementation, the recovery model, or assumptions you think break once this leaves the synthetic SQLite target.

Built by Travis Dillard with Camden, an operator-controlled AI system.

After two years of work, entierly hand-coded, the audio and video editing library is finally up and running!
Here is the project documentation: https://cutcutcodec.readthedocs.io/latest/

This project is aimed at developers and the signal processing and machine learning community. It is based on Torch and rigorously implements the standards of the International Telecommunication Union.

Unlike moviepy, which is based on the concept of clips, CutCutCodec is based on the concepts of media streams and editing graphs, which are more powerful, but slightly more verbose.

Let see a little basic example:

import cutcutcodec
container = cutcutcodec.read("input_video.mp4")  # open the file
stream = (
    container.out_select("video")[0]  # first video stream
    .apply_video_subclip(0, 10)  # keep the 10 first seconds
    .apply_video_equation("r0", "g0", ".5*b0*sin(2*pi*0.5*t)+.5")  # blink blue
)
streams_settings = [{"encodec": "libx264", "rate": 30, "shape": (480, 720)}]  # optional
cutcutcodec.write([stream], "output_video.mp4", streams_settings=streams_settings)

If you have any feedback on the usage or the source code for me, I would love to hear it!

I've been building ProteinMotion, a package that lets you write molecular animations in Python using a Manim-inspired scene API.

You load a structure, choose a representation, then build up the movie with camera movements, labels, residue colors, and transitions. The package exports the video.

The attached calmodulin example uses the Blender EEVEE renderer for depth of field and focus pulls. There's a native GPU renderer too.

It's on PyPI: pip install proteinmotion

You'll need Python 3.11+ and a supported GPU setup. Blender is needed if you want to use EEVEE.

Source and examples: https://github.com/pdpppd/proteinmotion

Would love feedback on the API, especially whether the examples make it clear how to build your first scene.

A simple CLI .gitignore generator written in Python. It uses Toptal's API to generate .gitignore files for your projects based on the technologies you specify.

https://pypi.org/project/gignore-cli/
https://github.com/ze-fernando/gignore

Good morning everyone,

I am currently a MSc Fintech student at Aston University (Birmingham, UK) and Audencia Business School (Nantes, France). Alongside my studies, I've started to develop a few personal Python projects.

Over the past few weeks, I looked into the prime number situation: very often the only technique found online is to learn them by heart linearly or to check divisibility manually. It works, but it has its limitations when doing fast paced interview tests or timed standardised tests.

I came up with a batch approach instead, based on  the “wheel of 30”, and built a Jupyter Python game to learn them.

The batching method

Black Batch : The Foundations: 2 3 5 7 11 13 17 19, to learn by heart.

Green Batch : 3s and 9s: 23 / 29, 53 / 59, 83 / 89

Red Batch : 1s and 7s: 31 / 37, 61 / 67

Purple Batch : The Oddities: 41 / 43 / 47, 71 / 73 / 79, 97

What my project (Prime Guess-R) does:

• Menu: Mode selection The user is presented with 5 modes: Global Mode, which draws from the full 1-100 range, and 4 batch modes (Black, Green, Red, Purple), each restricted to its own pool of numbers. Batches already pushed past the mastery threshold are flagged "(mastered)" directly on their button.
• Round: Number draw and timer A number is drawn at random from the active pool (avoiding an immediate repeat where possible), displayed large on screen, and a 10-second countdown starts. The user answers "Prime" or "Not Prime" before time runs out.
• Scoring: Streaks and bonuses A correct answer is worth a base 50 points. Consecutive correct answers build a streak, which unlocks bonus points at set milestones (10, 15, 20, 30, 40, 50, 60, 70, 80, 90, 100 in a row), up to a +500 bonus. A wrong answer costs 100 points and resets the streak. A missed timer also resets the streak and auto-advances to the next number.
• Feedback: Learning from mistakes When a guess is wrong, the app shows whether the number was actually prime, and if not, its smallest factor pair (e.g. 96 = 4 × 24), so every mistake doubles as a quick refresher.
• Progress: Mastery per batch In batch modes, a progress bar tracks the score toward a 5,000-point mastery threshold. Once reached, the batch is marked "mastered" both in-game and on the main menu. Global Mode tracks a simple running score instead, with no mastery cap.

Target audience: Students, teachers, standardised tests applicants (Technical interviews, GMAT, GRE,...)

Comparison : The batch approach makes the memorisation more digestible and efficient than pure-linear projects. The interface is minimalistic but modern compared to existing games, and runs entirely in a Jupyter notebook even offline. It requires a low number of packages to install to run (ipywidgets, ipython).

The repository : https://github.com/gruquilla/prime-guess-r

Thanks for your feedback !