(original) (raw)

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@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@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)