[Python-Dev] PEP487: Simpler customization of class creation

Martin Teichmann lkb.teichmann at gmail.com
Thu Jul 14 10:04:18 EDT 2016

Hi Nick, hi list,

> It would be worth spelling out the end result of the new behaviour in
> the PEP to make sure it's what we want. Trying to reason about how
> that code works is difficult, but looking at some class definition
> scenarios and seeing how they behave with the old semantics and the
> new semantics should be relatively straightforward (and they can
> become test cases for the revised implementation).

I agree with that. All the examples that Nick gives should work the
same way as they used to. I'll turn them into tests. I hope it is fine
if the error messages change slightly, as long as the error type stays
the same?

Let's look at an example that won't work anymore if my proposal goes throught:

    class MyType(type):
        def __new__(cls, name, bases, namespace):
            return super().__new__(cls, name=name, bases=bases, dict=namespace)

I guess this kind of code is pretty rare. Note that I need to call the
third parameter dict, as this is how it is named. Even if there is
code out there like that, it would be pretty easy to change.

Just in case someone wondered:

    def __new__(cls, **kwargs):
        return super().__new__(cls, **kwargs)

doesn't work now and won't work afterwards, as the interpreter calls
the metaclass with positional arguments.

That said, it would be possible, at the cost of quite some lines of
code, to make it fully backwards compatible. If the consensus is that
this is needed, I'll change the PEP and code accordingly.

My proposal also has the advantage that name, bases and dict may be
used as class keyword arguments. At least for name I see a usecase:

    class MyMangledClass(BaseClass, name="Nice class name"):



More information about the Python-Dev mailing list