Two minor syntactic proposals
Gareth McCaughan
Gareth.McCaughan at pobox.com
Sat Jun 16 20:53:43 EDT 2001
Here are two things that would make Python feel a little
nicer for me. (Which is not necessarily the same as "better",
of course.) I'd be interested in comments.
The proposals are extremely minor; they change the meaning
of no valid Python program and add no new semantics.
I conjecture that both would be easy to implement.
*
1. Syntax for extending an existing class.
Suppose you have a class and want to add a new method
to it. (Why? It's someone else's, you aren't allowed to
change the source, and subclassing won't do because
these things are created by code you don't control.)
You can do it, thus:
def new_method(self, x):
something_else()
return x+1
Thing.new_method = new_method
but that's rather ugly. I suggest that there be syntax
which does the same thing as the existing "class", but
updates an existing class instead of replacing it.
Two possibilities that don't require new keywords:
in class Thing:
def new_method(self, x):
something_else()
return x+1
or
class Thing continue:
def new_method(self, x):
something_else()
return x+1
I like the first of these much better than the second.
*
2. Syntax for defining methods.
Every now and then we get people complaining because it's
too easy for them to forget to include a "self" argument
in a method definition. Every now and then, I suspect that
most Pythonistas forget. (I certainly do.) Suppose there
were an alternative syntax, thus:
class Thing:
def self.boring_method():
return 0
That has two advantages: (1) it looks more the way that
the method will actually get used, and (2) it's harder
not to notice if you miss the "self." out.
I'm sure this one must have been proposed before, but I
don't see a PEP for it and have no recollection of why
(if it was proposed before) it was disliked.
--
Gareth McCaughan Gareth.McCaughan at pobox.com
.sig under construc
More information about the Python-list
mailing list