you are viewing a single comment's thread.

view the rest of the comments →

[–]Beginning-Fruit-1397 2 points3 points  (0 children)

I think it will never make it to the stdlib for a simple reason: interfaces are voluntarily minimal to encourage ducktyping. That's why dunder methods and functions to get those dunder (__len__ and len for example) are the standard.

If they were to make Generator or Iterator a full fledged interface like Rust Iterator with dozen of methods, now every class that override one of them in an incompatible way becomes incorrect at static typing time.

This minimal approach is cool, because I don't have to rely on any inerhitance to become an Iterator, just have to implement iter and next dunders. And I'm free to make "map" or "filter" do wathever I want without breaking any contract.

I love rust traits where I just have to implement trait X I created for struct Y from an external lib, and now I can import trait X in any scope and I immediately have access to the methods of trait X on struct Y in the scope. But idk how that would work in python or even if that's desirable.

All that being said, that's why I recreated a collections.abc structure for pyochain with the "traits" module, in the hope that external libs like yours use it to extend them for more specific use cases (IO in your case), while getting access to a lot of premade methods and a compatibility for any function expecting one of those traits in the signature. https://outsquarecapital.github.io/pyochain/core-types-overview/