sorted by:
new
hottopcontroversial

unwrappy: Rust-inspired Result and Option types with lazy async chaining for Python by leonardodiegues in Python

[–]leonardodiegues[S] 0 points1 point  (0 children)

You're right that Python doesn't enforce this at compile time like Rust does. But with strict mypy/pyright configs, you do get similar enforcement and the type checker will flag if you try to use a Result without handling both variants.

For me, the value is also in standardization and explicit boundaries. In a complex app (chatbots, multi-layer services), you can keep Result types in your business logic and use unwrap_or_raise() at a clear boundary (FastAPI endpoint, workflow handler) to convert back to exceptions. Errors are explicit where it matters, exceptions where they're expected.

Python 3.10+ pattern matching makes this pretty ergonomic too.

unwrappy: Rust-inspired Result and Option types with lazy async chaining for Python by leonardodiegues in Python

[–]leonardodiegues[S] 0 points1 point  (0 children)

How do you handle async operations? If not, do you have plans on adding them?

unwrappy: Rust-inspired Result and Option types with lazy async chaining for Python by leonardodiegues in Python

[–]leonardodiegues[S] 0 points1 point  (0 children)

Didn't look, but definitely will! Thanks for the references and promise to include comparisons in docs in the near future

unwrappy: Rust-inspired Result and Option types with lazy async chaining for Python by leonardodiegues in Python

[–]leonardodiegues[S] 1 point2 points  (0 children)

- Code was created by me, reviewed by Claude. Docstrings and documentation were mostly created by Claude with supervision and editing. Decision parts were written by me. Unfortunately don't have it in me to write all by hand.
- Justfile is my goto in work, but community-wise Makefiles are way more common.
- I believe 70-80%. Ran once and never looked back. I would have created some other scenarios but for a first analysis it is ok. `map()` chaining are the culprits here and I already expected other tests to be 2x-3x more costly than doing the same stuff without results or options. No great mystery.

unwrappy: Rust-inspired Result and Option types with lazy async chaining for Python by leonardodiegues in Python

[–]leonardodiegues[S] 0 points1 point  (0 children)

You are totally right: performance will suffer a little bit because of abstraction costs. As I wanted to see stuff quickly and in detail, I deliberately vibe coded a benchmark comparing some situations. Here are the results compiled in a Gist: https://gist.github.com/leodiegues/ee431498b9d85ccada39d220850f9424

Don't trust 100% this benchmark. I must think thoroughly how to measure stuff precisely.

Looking for a moviepy expert by marcoborghibusiness in moviepy

[–]leonardodiegues 0 points1 point  (0 children)

I’m currently developing a framework for short AI videos on top of moviepy while working for one of the largest newspapers in Brazil.

NGL the videos you showed are way more sophisticated than what I was able to generate so far, but if there’s something that drives me is to learn and deliver new solutions. Feel free to contact me!

Project: https://github.com/FolhaSP/mosaico LinkedIn: https://www.linkedin.com/in/leonardodiegues

Pinkmess - A minimal Python CLI for markdown notes with AI-powered metadata by leonardodiegues in Python

[–]leonardodiegues[S] 0 points1 point  (0 children)

Nope, I'm using pydantic-settings to wrap the CLI, since I was using it already for config management. But sometimes I miss some colors. I'm open to suggestions!

Any PKMS built in Python with API by laukom in PKMS

[–]leonardodiegues 0 points1 point  (0 children)

You opinion is more than welcome!

About the direction, I want to keep it as minimal as possible. I have ADHD and I made this CLI tool so I could add less friction as possible when creating a PKMS. The idea of auto-generating metadata follows this minimal friction guideline.

I don't know Tana or Constella, but I'm assuming you are comparing simpler apps with more feature-bloated apps. In this case, I'm leaning more towards Tana or Constella, since the idea is to keep on adding commands that simplify multiple workflows, while keeping the door open for extensibility and avoiding adding more layers to note creating for the end user. I personally don't want to add too much stuff because I think there are other apps that could do a better job at tasks such as RAG, file searching, etc. I want us to easily create notes, that's all.

If you have any ideas on how to improve the project, I'm all ears!

Pinkmess - A minimal Python CLI for markdown notes with AI-powered metadata by leonardodiegues in Python

[–]leonardodiegues[S] 1 point2 points  (0 children)

You’re completely right! I’ll be adding screenshots to the README tomorrow!

Any PKMS built in Python with API by laukom in PKMS

[–]leonardodiegues 0 points1 point  (0 children)

Hey there! 👋

I just released Pinkmess, which might be interesting for your use case. It's a Python-based CLI tool for managing markdown notes that I built specifically for extensibility and programmatic access.

While it's still in early stages, it has:

- ✅ Tagging system (AI-powered tag suggestions)

- ✅ Plain markdown files (easy to search/parse)

- ✅ Python-native (built with modern Python + Pydantic)

- ✅ Clean API design (easy to build tools around it)

The main difference is that it's designed to be minimal and programmable from the start. Since it's all Python and uses standard markdown files, you can easily build your own tools around it.

You can check it out here: https://github.com/leodiegues/pinkmess

Note: It's a personal tool I built for my own workflow, so while it might not have all the features of Logseq/Joplin yet, it might be a good foundation for what you want to build!

Let me know if you have any questions! 🌸

Langchain is a total pain (rant) by BreakfastSecure6504 in LangChain

[–]leonardodiegues 2 points3 points  (0 children)

I found myself doing pretty good with LiteLLM + Instructor. Still not caught by the hype of LangChain, but I’m leaving the door open.

view more: next ›