why not extending the syntax for classes, too ?

Michele Simionato mis6 at pitt.edu
Sun Feb 9 18:45:45 CET 2003


Erik, I would concede you that there is the possibility of confusion
between

def A is B:
   pass

and 

if A is B: do_something()

since in the first case "A is B" means "A is an instance of the
descriptor B"
whereas in the second case "A is B" means "A is the descriptor B". 
But I think this confusion would rarely arise, since in practical
cases one
would not use B as name of a descriptor or a metaclass, but readable
adjectives like

def f(x) is staticmethod:

or

class C is Traced:

Moreover, who is the typical user who is going to use the extended
syntax?
Is she a total newbie/beginner or somebody who already know what a
staticmethod is, what a metaclass is ? These idioms are for
experienced
Pythonistas, that is the reason why I think the probability of being
confused
with "is" denoting identity is 0.00001%. In addition to that, I think 
the "is" syntax forces the programmer to use *adjectives* for
descriptors
and metaclasses. Using adjectives makes the code easy to read and
understand
even for people who don't know what a staticmethod is and what a
metaclass is.

In order to avoid any possible confusion one could even use

def f(x) isinstanceof staticmethod:

and

class C(B) isinstanceof Traced:

but probably this would be a bit too verbose. At this point one could 
use the bracket syntax:

def f(x)[staticmethod]:

class C(B)[Traced]:

(here I mentally add the implicit "is"). 

I am not against the brackets, I am against "as" 


                                     Michele

P.S. even "as" is not safe, since the total beginner could think "def
f(x) as g:"  means that I have renamed "f" to "g"; but still, this is
academic since nobody would call a descriptor "g" and I think this
confusion to be very unlikely.




More information about the Python-list mailing list