Another Language Change for Debate

[IB]

Hello, Michael:

My 2 cents are that we have to ask one more question - what other
benefits would there be if such syntax would be allowed?

I would agree that it would be a neat thing, but after few minutes of
thinking on the subject I could not come up with anything extra...

So I believe that just one small benefit is not worth the hassle of
changing syntax. To my experience,language design always balances in
between innovation and conservative stability. It seems that
conservative approach would probably win here...

--Igor


Michael Chermside <mcherm at destiny.com> wrote in message news:<mailman.1010773286.16324.python-list at python.org>...
> 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