On 2019-09-29 21:15, Steven D'Aprano wrote:
Clearly we can't have an ABC for every imaginable combination of magic methods. There would be hundreds. What would we name them?
We should (and do!) have ABCs for the most common combinations, like Sequence, MutableMapping, Container etc.
And we should (so I am arguing) have ABCs for the underlying building blocks, the individual magic methods themselves. Developers can then combine those building blocks to make their own application-specific combinations.
But without those composable building blocks, we're reduced to testing for dunders by hand, which is problematic because:
- people get it wrong, using ``hasattr(instance, dunder)``
- ``getattr(type(instance), dunder, None) is not None`` is apparently still wrong, since that's not what collections.abc does, and presumably it has a good reason for not doing so.
- being part of the implementation, rather than public interface, in principle dunders may change in the future.
Obvious well-known dunders like __len__ will probably never go away. But the obvious and well-known dunder __cmp__ went away, and maybe one day the Sized protocol will change too. If you want to future-proof your code, you should test for the Sized interface rather than directly testing for the __len__ magic method.
I agree with this reasoning. I tend to be more of a "special cases aren't special enough to break the rules" kind of guy than a "practicality beats purity kind of guy". From my perspective, it doesn't really matter what you would or wouldn't use this ABC for. The ABC module is desirable at a conceptual level for providing just the type of implementation-agnostic facility you describe for querying the potential interface capabilities of objects. Getting items is a basic potential interface capability of objects and that alone is enough is enough justification for adding an ABC for it. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown