why not extending the syntax for classes, too ?
Michele Simionato
mis6 at pitt.edu
Mon Feb 10 08:12:50 EST 2003
bokr at oz.net (Bengt Richter) wrote in message news:<b2682f$hed$0 at 216.39.172.122>...
> On 7 Feb 2003 08:10:21 -0800, mis6 at pitt.edu (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
> >
> How about specialization or specialty or kind or narrowly or becomes?
> def double(x) specialization staticmethod:
> return 2*x
>
> def double(x) becomes staticmethod:
> return 2*x
>
> def double(x) kind 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. Metaclasses are typically denoted by adjectives and thus,
> >instead of writing, for instance
> >
> >class C(B):
> > __metaclass__=Traced
> > #assuming Traced is a metaclass adding tracing capabilities
> >
> >one could write
> >
> >class C(B) is Traced:
> > #This is much more readable
>
> class C(B) specialization Traced:
> #This is much more readable
>
> class C(B) becomes Traced:
> #This is much more readable
>
> Or we could use a suffix:
>
> def double(x) staticmethod'ly:
> return 2*x
>
> class C(B) Traced'ly:
> #This is much more readable
>
> ;-)
>
> Regards,
> Bengt Richter
I like "becomes" (even if 'ly is more fun ;-). But there are people against
not only new keywords, but also pseudo-keywords like "as" :-(
We will see what happens. More than the specific syntax, I like the
idea of specifying objects. And I always hope for a
def g() is/as/becomes generator:
Cheers,
Michele
More information about the Python-list
mailing list