A better self

[brueckd at tbye.com]

On Fri, 19 Jul 2002, Tom Loredo wrote:

> >   t, x, y, z=self.t, self.x, self.y, self.z
> >   result=sin(t)*x**y+sqrt(z)  # A pretend formula
[snip]
> to return various quantities.  In a language that boasts of how
> simple and straightforward it is, and how it shrinks code size (by
> omitting braces, declarations, etc.),
[snip]

The 'boasts' of course apply in the general sense, and in the general 
sense they are very true. From your perspective this is quite a nuisance 
because the combination of the types of programs you write and your design 
style make you encounter this problem often. 

>From your posts it sounds like you're trying to remain pretty positive
about this nuisance (good job!), but I hope you also realize that for a
lot of people writing a lot of programs there is no 'problem' - from my
perspective I hope that this whole 'self' thing never changes at all.

> in every one of many member functions, often with the same variables.
> You look at that code, with all those redundant lines of negligible
> content, and it yells out to you:  something is missing here that
> should make this silly copying unnecessary in order to have expressions
> that are easy to read/understand.

Hehe... well, changing the language is of course only one of your options,
and probably the least likely to ever pan out, especially for the
aforementioned reason that lots of people and lots of code already use
and/or like the other way. 

Every time this topic comes up I'm surprised at how desperately some
people want the language changed (not necessarily you, since you've
already said that it's not enough of a nuisance to abandon Python), and
I'm equally surprised that no combination of the following alternatives
are acceptable:

1) Learn to like it - I've spent more time reading about getting rid of 
self than time actually typing 'self.' (i.e. the costs are minimal and it 
makes my code more readable and explicit - it's worth it to me!)
2) Learn to just accept it (perhaps you find it annoying, but at least 
it's not something you deal with on every line of code)
3) Use the smarts of your editor - macros, special syntax highlighting, 
etc.
4) Use a shorter name than self, e.g. 's'
5) Use the x,y,z = self.x, self.y, self.z idiom
6) Have Python generate the function bodies for you, e.g:

   class SomeClass:
     method = MyCoolUnboundMethodMaker('arg:x = y*z + t*arg')

7) Change your design - if something is awkward it *may* be a flaw in the
language, but there's also a really, really good chance that a different
approach to your program would be best.

> The language is so great in other respects, and on a fundamental level
> the arguments for "self." are so sound, that I just live with this.

Fundamental, *and* practical, IMO. 

-Dave