<p dir="ltr">Hi everyone,</p>
<p dir="ltr">> > If the PEP 487 metaclass library,<br>
> > however, were to just port some bits of my code to Python 3 this could<br>
> > be a done deal already and available in *all* versions of Python 3,<br>
> > not just the next one.<br>
><br>
> Just for the heck of it, here's an actual implementation and demo of<br>
> PEP 487, that I've tested with 3.1, 3.2, and 3.4 (I didn't have a copy<br>
> of 3.3 handy):</p>
<p dir="ltr">The implementation mentioned in PEP 487 itself even works on <br>
python 2.7.</p>
<p dir="ltr">The whole point of PEP 487 was to reduce PEP 422 so much that<br>
it can be written in python and back-ported. This is also discussed in <br>
PEP 487. An updated discussion of PEP 487 can be found here:<br>
<a href="https://mail.python.org/pipermail/python-ideas/2015-March/032538.html">https://mail.python.org/pipermail/python-ideas/2015-March/032538.html</a></p>
<p dir="ltr">Now you want to be able to write decorators whose details<br>
are filled in at class creation time. Currently this is typically done<br>
by a metaclass. With PEP 487 in place this can also be<br>
done using a mixin class.</p>
<p dir="ltr">Your point is that you want to be able to use your decorators<br>
without having to ask users to also inherit a specific class.<br>
I personally don't think that's desirable. Many frameworks out<br>
there have such kind of decorators and mandatory base classes<br>
and that works fine. The only problem remains once you need to<br>
inherit more than one of those classes, as their metaclasses<br>
most likely clash. This is what PEP 487 fixes. It fixes this with<br>
just some handful lines of python code, but I consider that <br>
shortness an advantage.</p>
<p dir="ltr">So my opinion is that it is not too hard a requirement to ask<br>
a user to inherit a specific mixin class for the sake of using<br>
a decorator. What do other people think?</p>
<p dir="ltr">Greetings </p>
<p dir="ltr">Martin </p>