why not extending the syntax for classes, too ?

[Michele Simionato]

Erik Max Francis <max at alcyone.com> wrote in message news:<3E4467B5.4711E5F8 at alcyone.com>...
> Michele Simionato wrote:
> 
> > Within the proposals of extending the function syntax,
> > reported on the python-dev summary recently posted on c.l.p.,
> > I like the most the proposal with "is", as for instance in
> > 
> > def double(x) is staticmethod:
> >     return 2*x
> > 
> > I like the "is" syntax more than the syntax with "as" and the syntax
> > with the square brackets, especially because with "is"  it would be
> > natural to extend the notation for classes, using metaclasses as class
> > descriptors.
> 
> I'm lukewarm on the whole idea, but I think I'd prefer "as" to "is" in
> this context.  "is" is a very important (and very specific) operator in
> Python, and it's being used as an auxiliar syntax hint in a context
> totally different from that which the "is" operator actually takes.
> 
> The "as" keyword, on the other hand, already exists in this auxiliary
> capacity for the "import X as Y" statement, making it a much better
> choice as an auxiliar signal in a syntactic context than a keyword that
> already means something very specific and wholly unrelated.

I would agree with you with the use in functions, however my point here is
that "is" can be extended to classes, whereas "as" cannot.

Four reasons why I'd like to write "class <name> is <adjective>", in order
of relevance:

1) force people to denote metaclasses with adjectives, which is
the right thing to do;
2) enhance readability;
3) get rid of the __metaclass__ hook (too many underscores are hackish, IMHO)
4) consistency between the syntax for functions and classes (even if the
meaning would be different, since descriptors are not metaclasses,
but still they have the same goal of adding an adjective to a function/class).

Yes, the price to pay is to overload "is", but I don't think this would
case confusion to anybody.

                             Michele