Another Language Change for Debate

Michael Chermside mcherm at destiny.com
Fri Jan 11 13:21:34 EST 2002


Okay, for some reason this newsgroup tends to get WAY more suggestions 
for language changes than that for any other language that I know. I 
suppose that there are a couple of reasons for this. One is cultural, 
another is that Python definitely IS being improved and extended 
(witness brilliant advances like iterators, generators, and the 
beginnings of a fix for the type-class chasm). My conceit is that 
another reason is that Python is so VERY nice already that it's the 
language to which most people want to add their own pet idea. But I 
suspect that the NUMBER ONE reason is that the people who read and write 
on c.l.p are, on the whole, VERY GOOD at language design.

So I'll throw out an idea of my own for discussion. This is NOT a PEP... 
and therefore NOT a serious proposal for a change in Python. I just want 
to hear what other people think about it and compare your sense of 
language design with my own.

One of the things that still throws me in Python is writing things like 
this:

class MyClass(OtherClass):
    def addItems( newItems ):
       self.items += newItems

Of course what I've forgotten to do here is to declare 'self' as the 
first parameter to addItems(). The reason I forgot is that when I CALL 
the method it looks like this:
      myObj.addItems( userItems )
so when I'm writing it I'm thinking of it as a function of one parameter.

Proposals for leaving off 'self' have been made many times, but that's a 
bad idea... the fact that every variable reference is (1) local, (2) 
nested scoped, or (3) global and can be found by a simple textual search 
through the source code is a VERY ELEGANT thing about Python. But 
writing the method one place with 2 arguments and another place with 
just 1 is not elegant.

So here's my idea. Allow the following syntax:

class MyClass(OtherClass):
    def self.addItems( newItems ):
       self.items += newItems

So in method declarations where we normally permit only an identifier 
for the method-name, we now allow also identifier '.' identifier. The 
identifier before the dot simply becomes the first parameter of the 
method. I don't think it would be good style to use this for non-methods 
(ie, normal functions not belonging to a class), but I suppose there's 
no reason to prohibit the syntax. There's no way to set default values 
for this parameter, but you don't do that with 'self' anyhow, right?

As far as I can tell, there'd be no syntactic ambiguity (please correct 
me if I've missed something). And it would make the DECLARATION of a 
method look a whole lot more like the USE of the method, without 
removing the elegance of declaring 'self' like any other variable.

So... what do you folks think?

-- Michael Chermside





More information about the Python-list mailing list