On 13 October 2017 at 19:35, Martin Teichmann <lkb.teichm...@gmail.com>
wrote:
> > Metaclasses currently tend to serve two distinct purposes:
> >
> > 1. Actually altering the runtime behaviour of a class and its children in
> > non-standard ways (e.g. enums, ABCs, ORMs)
> > 2. Boilerplate reduction in class definitions, reducing the amount of
> code
> > you need to write as the author of that class
> >
> > Nobody has a problem with using metaclasses for the first purpose -
> that's
> > what they're for.
>
> I am that nobody. The examples you give would be much nicer solved
> with decorators. Especially for ABCs it would be much better, because
> the fact that a class is an ABC is explicitly not inherited - its
> entire reason of existence is to be inherited with all the
> abstractness going away. And yet, currently the concrete class will
> still inherit from ABC.
Aye, ABCs are definitely a case where I think it would be valuable to have
a class decorator that:
1. Transplants any concrete method implementations from the ABC
2. Ensures that the class being defined actually implements all the
required abstract methods
The register method doesn't do either of those things, while inheritance
has the unwanted side-effect of changing the metaclass of even concrete
subclasses.
As a handwavey concept, something like:
@abc.implements(collections.Mapping)
class MyMapping:
... # Just implement the abstract methods, get the rest injected
So I am personally more and more leaning towards a metaclass-free future.
>
I agree with this view in the sense that I'd like the number of use cases
that *require* a custom metaclass to get ever smaller (replacing them with
regular inheritance + definition time method injection), but I also think
they'll always have a place as a way for folks to explore the design space
of what's possible given full control over the class definition process.
That way, proposals like __init_subclass__ and __set_name__ can be based on
pattern extraction from cases where people have decided the feature was
valuable enough to be worth the hassle of maintaining a custom metaclass.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
