[Python-3000] PEP for Metaclasses in Python 3000

[Josiah Carlson]

"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.


 - Josiah