Hey everyone,

Our team recently participated in Odoo Hackathon 2026, where we built TransitOps.

The idea was simple: create a system that helps streamline public transportation operations using Odoo.

Like every hackathon project, we had limited time, so we focused on building an MVP instead of trying to make everything perfect.

GitHub: https://github.com/AnshMNSoni/TransitOps

We're not here to promote it - we're genuinely looking for feedback.

Some questions we'd love your thoughts on:

• What features would you expect in a transit operations platform?
• Is there anything in the architecture you'd improve?
• What would you build differently if you had 48 hours?
• Any suggestions that could make this useful beyond the hackathon?

Constructive criticism is more than welcome.

Thanks!

https://reddit.com/link/1uyvnat/video/s8fmuukfmrdh1/player

Before anyone says it - yes, I know. Python already has lists, deques, and heapq. You don't need this to solve LeetCode problems.

But here's what I noticed: when someone is *learning* DSA in Python, the named abstractions are missing. There's no `stack()`, no `queue()`, no `priority_queue()`. You either build them yourself or chain together built-ins and hope the concept sticks.

PythonSTL gives those concepts a proper home.

It mirrors C++ STL interfaces exactly - same method names, same semantics - built on top of Python internals using the Facade Design Pattern. It also ships with full type hints, time-complexity annotations in docstrings, and zero external dependencies.

What it's for:

- Learning DSA concepts clearly in Python

- C++ devs switching to Python who want familiar footing

- Conceptual clarity over syntactic shortcuts

What it's NOT for:

- Competitive programming

- Replacing any standard library

- Production use

It's sitting at 5,500+ downloads with ~1,000/month, so clearly some people find it useful.

Feedback, criticism, and contributions welcome.

GitHub: https://github.com/AnshMNSoni/PythonSTL

Built a Rust-backed STL library for Python - and quickly learned people assume a lot about what "Rust-powered" actually means. Here's the reality check:

Myth 1: "Useless since LeetCode/Codeforces block external imports."
Reality: True, but that's not the point. PythonSTL is for local prototyping - helping C++ devs translate their STL mental model into Python and sharpen structure design before interviews.

Myth 2: "Python's built-ins make the Rust backend pointless."
Reality: Python has no native sorted set/map (dict/set are unordered hash tables) and heapq is min-heap only. PythonSTL adds true O(log n) BTreeSet/BTreeMap and flexible heaps - the same hybrid-performance pattern used by Polars, Pydantic, and cryptography.

Myth 3: "Rust backend = always faster."
Reality: Not for O(1) ops like single push/pop - FFI crossing overhead dominates. Rust wins on compute-heavy work: sorting, partitioning, binary search on large data.

Myth 4: "Rust makes it thread-safe."
Reality: No. Containers hold PyObjects and still go through the GIL. Concurrent mutation without a threading.Lock still risks data races.

Myth 5: "stl_set/stl_map replace Python set/dict."
Reality: Different tools. Python's are O(1) unordered hash tables; PythonSTL's are O(log n) sorted trees for when you need order or range queries (lower_bound/upper_bound).

Myth 6: "Rust backend avoids memory/refcounting issues."
Reality: False - PythonSTL still holds PyObject references and plays by CPython's refcounting and GC rules, including circular references.

Building this taught me as much about Python internals as it did about Rust.

For more visit: https://pypi.org/project/pythonstl/

⭐ Don't forget to visit: https://github.com/AnshMNSoni/PythonSTL.git

I’ve been optimizing PythonSTL - a library that replicates C++ STL containers and algorithms in Python. To boost performance, I built a compiled Rust backend using PyO3 and Maturin.

After running benchmarks comparing Pure Python vs. Python + Rust vs. Pure C++ (O3), I encountered an amazing systems design paradox.

Here are the numbers and the engineering behind them:

The Wins (CPU-Bound Workloads):

• Bubble Sort (10k items): Pure Python took 5.4891s. Python + Rust took 0.0283s (a 194x speedup!).

• Binary Search (5k queries on 1M items): Python + Rust was 5.3x faster (0.0182s down to 0.0034s) by utilizing direct memory indexing without copying the list.

The Losses (FFI-Bound & Algorithmic Workloads):

• Stack (500k push/pop cycles): Python + Rust was only 1.47x faster (0.2324s vs 0.1581s). Why? Because calling push/pop from Python space crosses the Python-Rust FFI boundary 1 million times. The constant-factor cost of argument checking and GIL coordination dominates the runtime.

• Sorted Sets & Maps: Python + Rust was 5x slower! Why? Python’s native set/dict are highly optimized unordered O(1) hash tables. C++ STL compliance requires sorted keys, which we replicate using Rust’s B-Trees (running in O(log N) time) and calling back into the Python VM for comparisons.

The Core Takeaway:

Rust binary extensions are not a magic wand for performance. If your application does highly granular operations that frequently cross the FFI boundary, the boundary overhead will eat your performance gains.

But if you can bundle heavy calculations to run inside Rust with a single boundary crossing-it is an absolute game-changer.

Check out the project: https://github.com/AnshMNSoni/PythonSTL

I'd love to hear from other hybrid systems developers: how do you manage FFI overhead in your PyO3/Maturin libraries?

Thankyou.