Project Status

[francium]

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

[wbolster]

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]

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).

thanks for your time and effort over the years, @francium! ❤️🤗

I second that! 🙂

[ksdaftari]

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]

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

• Use TypeIs instead of TypeGuard Replace TypeGuard with TypeIs #194 (@kreathon)
• Added Python 3.13 (Add support for Python 3.13 #181 feat(python): support for 3.13 #195 )
• Added support for @as_generator_result and @as_async_generator_result, which function like @as_result but wrap the yield values of a generator (similar to adapt as_result and as_async_result so they can accept generators #187)
• Allow bubbling up unwrapping of nested Result inside the @as_* decorated classes. If you unwrap an Err of an exception type that you handle in the generator, it will return that Err(Exception)from the decorated function as if you had thrown the Exception directly.

Other

• Dropped Python 3.8 & 3.9 to simplify maintenance (Remove support for Python 3.8 after 2024-10 #180 Remove support for Python 3.8 #196)
• Switch to a uv build system with hatch
• Switched linter to Ruff

[indigoviolet]

@dbrgn @wbolster It would be useful to hear more about your thoughts on the technical limitations of this style of programming in Python.