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

Nick Coghlan ncoghlan at gmail.com
Fri Apr 3 03:31:04 CEST 2015

On 3 April 2015 at 08:24, Martin Teichmann <lkb.teichmann at gmail.com> wrote:

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?

If I'm understanding PJE's main concern correctly it's that this approach requires explicitly testing that the decorator has been applied correctly in your automated tests every time you use it, as otherwise there's a risk of a silent failure when you use the decorator but omit the mandatory base class that makes the decorator work correctly.

I'm actually OK with the "mandatory base class" approach myself - it's the way most Python frameworks operate, and it acts as a visible indicator of the "concept space" a particular class is operating in (e.g. "Django Form", "SQL Alchemy Model") rather than having that information be implicit in the decorators being used.

However, I'm also now wondering if it may be possible to reach out to the pylint authors (similar to what Brett did for the "pylint --py3k" flag) and ask for a way to make it easy to register "base class, decorator" pairs where pylint will complain if it sees a particular method decorator but can't determine at analysis time if the named base class is in the MRO for the class defining the method.

Regards, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list