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.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. 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)
_______________________________________________ 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
