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"): pass Greetings Martin