I'm a big fan of @mhashemi's work in Python in general, even if I don't use Boltons personally. The discussion regarding inclusion in the stdlib is sensible, a

I'm a big fan of @mhashemi's work in Python in general, even if I don't use Boltons personally. The discussion regarding inclusion in the stdlib is sensible, and I fully agree with @mhashemi's comments. See similar discussions, for instance, regarding dataclasses vs. attrs (https://github.com/ericvsmith/dataclasses/issues/19 https://github.com/ericvsmith/dataclasses/issues/19). Sometimes, however, it's a bit annoying when something that you think should be widely available isn't included in the stdlib. The cons of course are: - Fragmentation (several project pursuing similar objectives) - Not being able to use a powerful construct to simplify code in the stdlib itself (the stdlib can only depend on the stdlib). Regarding, for instance, functional programming, I maintain a list of interesting projects in this domain in Python: https://github.com/sfermigier/awesome-functional-python/blob/master/README.md#libraries https://github.com/sfermigier/awesome-functional-python/blob... There are at least half a dozen libraries that strive to achieve similar goals, and would probably benefit from being included in the stdlib (at least partially). It's hard to pick a winner among the list (like other in this thread, I went with toolz). I believe that a way to solve (at least partially) this conundrum could be to work on some common specifications, like the JS community did with Fantasyland (https://github.com/fantasyland/fantasy-land https://github.com/fantasyland/fantasy-land), and then let projects implements the specification the way they want. WDYT ?