optype for toolz and cytoolz: ambitious or foolish?

[hunterhogan]

In Z0Z_tools, I've been modernizing and adding type annotations to toolz and cytoolz.

I haven't used optype before. If I were to raise the Python minimum to 3.12, would optype be a good fit for these packages?

[jorenham]

In Z0Z_tools, I've been modernizing and adding type annotations to toolz and cytoolz.

Awesome 💪

I haven't used optype before. If I were to raise the Python minimum to 3.12, would optype be a good fit for these packages?

Yea definitely!

For example, itertoolz.pluck and itertoolz.get accepts anything with a __getitem__ method, so optype.CanGetitem[K, V] would be the most correct solution (Sequence/Mapping needlessly require a bunch of extra methods like __len__ and __contains__ to be present, even though these aren't used at all).

And for itertools.merge_sorted and other sorted-like functions such as topk only require the items to be comparible, for which optype.CanLt and optype.CanGt are the best choices.

For the dicttoolz merge and map functions you mostly need iteration (optype.CanIter) and __getitem__ (optype.CanGetitem), not a full Mapping. So a simple class CanIterAndGetitem(optype.CanIter, optype.CanGetitem) (+ some generic params) would be the cleanest way to go here.

However, optype won't help everywhere. For example the rather involved functoolz functions won't benefit much from optype. Or at least, not directly. Because there's optype infer (docs), which can be very handy for figuring out how these functions could be best annotated in a runtime-verified and type-sound way.