On Tue, 8 Feb 2022 at 00:09, Neil Girdhar <mistersheik@gmail.com> wrote:
>
> Currently, some type checkers rightly complain that a method is decorated with abc.abstractmethod when the class's type does not inherit from ABCMeta. Adding a metaclass is a fairly heavy dependency since you're forced to poison all of your other metaclasses with the same base metaclass. It also brings in possibly unwanted type registration that ABC comes with.
>
> Now that abstractmethod's usage is extremely well-understood, would it make sense to move the checking logic out of ABCMeta?
>
> It could either be put into object so that no base class is necessary (at the cost of slightly slower class creation), or else in a non-meta base class (say, HasAbstractMethods) now that __init_subclass__ is in all extant versions of Python. Inheriting from such a non-meta base class would avoid the poisoning problem described above.
>
> As far as I can tell, neither solution breaks code.
If it's valid usage, why not just get the type checkers fixed?
I don't think that the type checkers need to be fixed.
Or if,
as you say, the type checkers are complaining correctly, why do you
want to do it?
The main motivation is that adding a metaclass is a fairly heavy dependency since you're forced to poison all of your other metaclasses with the same base metaclass. It also brings in possibly unwanted type registration that ABC comes with.
Also, I can't prevent the type checker warnings and it takes weeks to submit pull requests and convince projects I use to add the base class and explain the error. It would save everyone time if these errors didn't happen in the first place.
So, pulling this functionality into object would just eliminate the whole problem, and as far as I can tell doesn't cause any? It also lowers the bar for usage of abc.abstractmethod.
Paul