[Python-Dev] PEP 487 vs 422 (dynamic class decoration) (original) (raw)

Martin Teichmann lkb.teichmann at gmail.com
Fri Apr 3 00:24:53 CEST 2015

Hi everyone,

> If the PEP 487 metaclass library, > however, were to just port some bits of my code to Python 3 this could > be a done deal already and available in all versions of Python 3, > not just the next one.

Just for the heck of it, here's an actual implementation and demo of PEP 487, that I've tested with 3.1, 3.2, and 3.4 (I didn't have a copy of 3.3 handy):

The implementation mentioned in PEP 487 itself even works on python 2.7.

The whole point of PEP 487 was to reduce PEP 422 so much that it can be written in python and back-ported. This is also discussed in PEP 487. An updated discussion of PEP 487 can be found here: https://mail.python.org/pipermail/python-ideas/2015-March/032538.html

Now you want to be able to write decorators whose details are filled in at class creation time. Currently this is typically done by a metaclass. With PEP 487 in place this can also be done using a mixin class.

Your point is that you want to be able to use your decorators without having to ask users to also inherit a specific class. I personally don't think that's desirable. Many frameworks out there have such kind of decorators and mandatory base classes and that works fine. The only problem remains once you need to inherit more than one of those classes, as their metaclasses most likely clash. This is what PEP 487 fixes. It fixes this with just some handful lines of python code, but I consider that shortness an advantage.

So my opinion is that it is not too hard a requirement to ask a user to inherit a specific mixin class for the sake of using a decorator. What do other people think?

Greetings

Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150403/23ab21dc/attachment.html>

More information about the Python-Dev mailing list