why not extending the syntax for classes, too ?
Michele Simionato
mis6 at pitt.edu
Sun Feb 9 12:45:45 EST 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