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

[Nick Coghlan]

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