Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171013/50eaeb11/attachment-0001.html below:
<div dir="ltr"><div><div><div>This is food for thought. I'll have to let it sink in a bit, but you may be on to something.<br><br>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 (<a href="https://www.amazon.com/Putting-Metaclasses-Work-Ira-Forman/dp/0201433052">https://www.amazon.com/Putting-Metaclasses-Work-Ira-Forman/dp/0201433052</a>) and translated the book's ideas from C++ to Python, except for the automatic merging of multiple inherited metaclasses.<br><br></div>But in many cases class decorators are more useful.<br><br></div>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.)<br><br></div>--Guido<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 2:35 AM, Martin Teichmann <span dir="ltr"><<a href="mailto:lkb.teichmann@gmail.com" target="_blank">lkb.teichmann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Metaclasses currently tend to serve two distinct purposes:<br>
><br>
> 1. Actually altering the runtime behaviour of a class and its children in<br>
> non-standard ways (e.g. enums, ABCs, ORMs)<br>
> 2. Boilerplate reduction in class definitions, reducing the amount of code<br>
> you need to write as the author of that class<br>
><br>
> Nobody has a problem with using metaclasses for the first purpose - that's<br>
> what they're for.<br>
<br>
</span>I am that nobody. The examples you give would be much nicer solved<br>
with decorators. Especially for ABCs it would be much better, because<br>
the fact that a class is an ABC is explicitly not inherited - its<br>
entire reason of existence is to be inherited with all the<br>
abstractness going away. And yet, currently the concrete class will<br>
still inherit from ABC. The following way of writing ABCs looks much<br>
nicer to me:<br>
<br>
  @abstractclass<br>
  class Spam:<br>
    @abstractmethod<br>
    def ham(self):<br>
       ...<br>
<br>
The same holds for enums. Inheriting from enums is possible, but<br>
weird, given that you cannot add new enums to it. So, especially when<br>
comparing to the dataclasses, the following looks appealing to me:<br>
<br>
  @enum<br>
  class Breakfast:<br>
    spam = 0<br>
    ham = 1<br>
<br>
I'm not an expert on ORMs, but they seem to me a lot like data classes<br>
in the context of this discussion.<br>
<br>
I am aware that currently some things are easier done with<br>
metaclasses. But given that decorators can create an entirely new<br>
class if they like, they have all the power to do what they want, and<br>
even in a way much easier understood by people.<br>
<br>
As an example, here the autoslot decorator:<br>
<br>
  def autoslot(cls):<br>
    """turn all class variables into slots"""<br>
    cls.__slots__ = list(cls.__dict__)<br>
    return type(cls.__name__, cls.__bases__, class.__dict__)<br>
<br>
So I am personally more and more leaning towards a metaclass-free future.<br>
<br>
Cheers<br>
<br>
Martin<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4