On Sun, Nov 28, 2021 at 11:28 AM Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Nov 29, 2021 at 6:01 AM Christopher Barker <pythonchb@gmail.com> wrote:
But we *could* define a new ChainedIterator ABC. Anyone could then subclass from it to get the chaining behavior, and we could (potentially) use it for many of the iterators in the stdlib.
I'm not sure I'd even support this, but it's an idea.
I wouldn't support it. One of the great things about Python is that it's fairly easy to teach this progression:
1) Here's how you can do stuff in a generic way 2) Here's how you can make your own thing fit that generic way 3) Now your thing can be used by anyone else using #1
<snip of good examples of protocol-based duck typing> Sure, but I"m not sure it's THAT much harder to say: If you want to make an iterator, define a __next__ method. If you want to make a ChainableIterator, derive from abc.ChaibableIterator -- it will give you some nifty stuff for free. And some of the current ABCs do provide some out of the box functionality right now. It would take someone other than me to explore this idea further, I'm not sure I even want it. But it struck me that one of the reasons we don't want to add functionality to existing ABCs is that it would suddenly make other types that currently conform to the ABC, but don't derive from it, no longer valid. ANd with the proliferation of type checking, that would be a mess. But if we create a new ABC that extends an existing protocol, it wouldn't break anything. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython