Repository navigation
Project Status: UNMAINTAINED #201
Description
Hi everyone,
I've been meaning to write this for a long time. As can be noticed from the queue of PRs and unanswered issues, this project is no longer receiving the attention and maintenance it needs. As a volunteer project, it needs people who are willing to commit time to make sure the things are running smoothly. For a long time, I've been the primary maintainer. But now I'd be lying to myself and everyone else if I said I'm will be able to continue maintaining this project and give it the time and attention it needs.
I believe the best thing now is:
- make this announcement to let users of this library know it will no longer be maintained, no more releases will be made, no more fixes or features
- anyone interested in doing so is welcome to fork this project and re-release it under the terms of the project's license, and maintain it under new management
My rationale for not welcoming new maintainers for this project is because (1) I do not have the capacity to oversee a transition, (2) I do not know of anyone I trust enough that I can hand this project off to immediately, (3) handing the project to an unknown party is not in the best interest of current users of this library.
cc @dbrgn @wbolster if by any chance either of you are interested in taking up maintenance of this project please let me know
Activity
wbolster commentedon Dec 23, 2024
unfortunately i feel the same, and will not be stepping up my efforts.
i have come to the conclusion that this style of programming simply does not lend itself well to the python ecosystem, both for technical and cultural reasons, and it looks like it will remain an ‘odd’ niche.
thanks for your time and effort over the years, @francium! ❤️🤗
dbrgn commentedon Dec 27, 2024
Hi folks. Same thing from me, I feel like algebraic data types only have limited practical use in Python compared to languages with first-class support (like Rust or Haskell).
I second that! 🙂
delulu3i4 commentedon Jan 3, 2025
Thanks for work have done in this and pushing boundaries. I be curious what have learned in this experience especially where something like this doesn't seem to work in python paradigm, on surface definitely feels nice, but assuming some what found is even if python culturally adopted such paradigms there is some limitations living in it, that be curious to hear on?
montasaurus commentedon Jan 8, 2025
Thanks so much for all your work on this library @francium !
I've been working off a fork of it for my own projects. It's not production tested yet, so use at your own risk. I might package and publish it if there's demand, but you can install it directly from the repo for now.
Features
@as_generator_resultand@as_async_generator_result, which function like@as_resultbut wrap the yield values of a generator (similar to adaptas_resultandas_async_resultso they can accept generators #187)Resultinside the@as_*decorated classes. If you unwrap anErrof an exception type that you handle in the generator, it will return thatErr(Exception)from the decorated function as if you had thrown the Exception directly.Other
indigoviolet commentedon Jan 17, 2025
@dbrgn @wbolster It would be useful to hear more about your thoughts on the technical limitations of this style of programming in Python.
notypecheck commentedon Feb 13, 2025
Using errors as types approach was very useful to me when writing any business logic, since if you just throw exceptions any typing information tends to be lost. Only way to document what exceptions could be raised from a function is by using docstrings, which don't provide any typing.
Currently the main problem with this approach is just verbosity due to type checkers not recognizing a lot of things (e.g. using match with
Err(SomeType)andOk(SomeOtherType)won't narrow down their contents inside of thecaseblock), hopefully some of the pains could be solved with https://peps.python.org/pep-0638/ if it would be accepted and type checkers would support it too.TamerSoup625 commentedon Dec 19, 2025
Thank you so much, @francium ! Your package really helped me get going the development of my
guardsmodule. It basically implements an alternative to Python'stry/except/elsestatements, effectively usingResult-like values only when you want to handle exceptions. Without taking your source code as a base, I feel like it would've taken a lot more time just to get the typing to work 😅.Thanks again for all your efforts ❤️. Maybe this new library will suit better the Python ecosystem.
wbolster commentedon Jun 25, 2026
yo @francium @dbrgn what do you think of archiving this github repo? (essentially that makes it read-only.) i think it's a good idea. if you agree, lmk and i'll put a note in the readme prior to archiving it.
francium commentedon Jun 25, 2026
@wbolster I think that's a good idea at this point. If you don't mind. Thank you for the help! :)
The other repo would be good to archive too, maybe.
[-]Project Status[/-][+]Project Status: UNMAINTAINED[/+]wbolster commentedon Jun 25, 2026
cool, i've just added a note to the readme, and closed all open issues and pull requests with a comment pointing to this ticket.
thanks for the ride, everyone! 🤗🤓