[Python-3000] PEP for Metaclasses in Python 3000 (original) (raw)

Josiah Carlson jcarlson at uci.edu
Tue Mar 13 22:26:48 CET 2007

"Guido van Rossum" <guido at python.org> wrote:

On 3/13/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: > I'm a bit worried that class headers are going to become > rather cluttered if we start putting all sorts of stuff > in there. > > E.g. are you intending to put slots there? It makes > sense, but it could lead to some rather long and > unwieldy class headers.

It makes sense to put slots there, doesn't it? I'm not too worried about the long class headers; a formatting convention can do wonders here.

I agree that formatting can do wonders, but it smells a bit like the discussion that was had way back when we were discussing function decorators. If I remember correctly, one reason why decorators didn't end up in the function signature was because it makes the function signature unruly in the case of many decorators. While class headers are significantly more rare than function or method definitions, I can't help but think that some sort of 'pre-decorator' syntax wouldn't look a bit better. Say something like @@(*args, **kwargs). For a shorter example, it doesn't look much (if any) better...

class F(implements=(I1, I2)):
    ...

vs.

@@(implements=(I1, I2))
class F:
    ...

But in slightly longer examples, I think that the looks are significantly improved...

class Foo(base1, base2, *otherbases, metaclass=mymeta,
    private=True, **kwargs):
    ...

vs.

@@(metaclass=mymeta, private=True, **kwargs)
class Foo(base1, base2, *otherbases):
    ...

The 'pre-decorator' (which only makes sense for classes) could serve as the location where all **kwargs are passed to the prepare method on the provided metaclass, with the class header allowing *args, which are provided to both prepare and whatever method is called on the metaclass.

More information about the Python-3000 mailing list