Yes, I see what you're saying. However, I don't understand why __init_subclass__ (defined on some class C) cannot be used to implement the checks required by @abstractmethod instead of doing it in ABCMeta. This would prevent metaclass conflicts since you could use @abstractmethod with any metaclass or no metaclass at all provided you inherit from C.
On 19 July 2016 at 09:26, Neil Girdhar <mistersheik@gmail.com> wrote:
> Yes, I'm very excited about this!
>
> Will this mean no more metaclass conflicts if using @abstractmethod?
ABCMeta and EnumMeta both create persistent behavioural differences
rather than only influencing subtype definition, so they'll need to
remain as custom metaclasses.
What this PEP (especially in combination with PEP 520) is aimed at
enabling is subclassing APIs designed more around the notion of
"implicit class decoration" where a common base class or mixin can be
adjusted to perform certain actions whenever a new subclass is
defined, without changing the runtime behaviour of those subclasses.
(For example: a mixin or base class may require that certain
parameters be set as class attributes - this PEP will allow the base
class to check for those and throw an error at definition time, rather
than getting a potentially cryptic error when it attempts to use the
missing attribute)
Cheers,
Nick.
--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia