[Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

[Guido van Rossum]

This is food for thought. I'll have to let it sink in a bit, but you may be
on to something.

Since the question was asked at some point, yes, metaclasses are much older
than class decorators. At some point I found the book Putting Metaclasses
to Work by Ira Forman and Scott Danforth (
https://www.amazon.com/Putting-Metaclasses-Work-Ira-Forman/dp/0201433052)
and translated the book's ideas from C++ to Python, except for the
automatic merging of multiple inherited metaclasses.

But in many cases class decorators are more useful.

I do worry that things like your autoslots decorator example might be
problematic because they create a new class, throwing away a lot of work
that was already done. But perhaps the right way to address this would be
to move the decision about the instance layout to a later phase? (Not sure
if that makes sense though.)

--Guido

On Fri, Oct 13, 2017 at 2:35 AM, Martin Teichmann <lkb.teichmann at 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. The following way of writing ABCs looks much
> nicer to me:
>
>     @abstractclass
>     class Spam:
>         @abstractmethod
>         def ham(self):
>              ...
>
> The same holds for enums. Inheriting from enums is possible, but
> weird, given that you cannot add new enums to it. So, especially when
> comparing to the dataclasses, the following looks appealing to me:
>
>     @enum
>     class Breakfast:
>         spam = 0
>         ham = 1
>
> I'm not an expert on ORMs, but they seem to me a lot like data classes
> in the context of this discussion.
>
> I am aware that currently some things are easier done with
> metaclasses. But given that decorators can create an entirely new
> class if they like, they have all the power to do what they want, and
> even in a way much easier understood by people.
>
> As an example, here the autoslot decorator:
>
>     def autoslot(cls):
>         """turn all class variables into slots"""
>         cls.__slots__ = list(cls.__dict__)
>         return type(cls.__name__, cls.__bases__, class.__dict__)
>
> So I am personally more and more leaning towards a metaclass-free future.
>
> Cheers
>
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171013/50eaeb11/attachment-0001.html>