Repository navigation
the future of happybase #233
Description
Activity
I should have my third idea for merging the two forks (where async is the default) fleshed out by tomorrow.
With that finished, it wouldn't be very hard at all to create a happybase package that just inverts the imports of the aiohappybase package to provide the strict supperset without code duplication that could serve as a nice transition period.
Reacted by wouter bolsterleeReacted by wouter bolsterleeI've finished the "sync as a sub-package" implementation: https://github.com/aiudirog/aiohappybase/pull/3
It's a little hacky in its pursuit of code dryness but I think that's okay because in theory it will nearly guarantee the two implementations don't diverge without having to code everything twice.
this is fantastic, thank you for all your work
Reacted by aiudirog- pinned this issue
on Sep 26, 2025
considering that:
aiohappybasework modernizes the code to be python3.6+ onlyit may be good for happybase's future if:
aiohappybasefork if it becomes a strict superset of the original happybase, which seems technically feasible (https://github.com/aiudirog/aiohappybase/pull/1, https://github.com/aiudirog/aiohappybase/pull/2)thoughts welcome, especially from @aiudirog (with whom i also have had recent email contact).