"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 3/13/07, Greg Ewing <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
