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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/HWHP4LNDJW7YV2G3GGX3HBPZ426N67VE/
Code of Conduct: http://python.org/psf/codeofconduct/
