Home Original page

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