“Too many ’self’ in python.That’s a big flaw in this language.”
The title is of course not my creation - it is another thread on comp.lang.python (serious, you should stop by, I lurk a lot and read posts from that xiu fellow).
In this particular thread:
I'm currently using Python. I find that a instance variable must
confined with self,
for example: [snip] That's a big inconvenience in coding ,especially when you have lot of variable If you method need 10 variables ,you have to type "self" for 10 times and that also makes your variable longer. From My point,I think this only help python interpreter to deside where to look for. Is there anyone know's how to make the interpreter find instance name space first?
Or any way to make programmer's life easier?
That's the original post. Without delving too deep into the nuances of his critique - I like explicit self. As Bjorn wisely points out "Explicit is better than implicit.
I really don't understand the near visceral dislike of "self." some people have. I mean, "self" you're passing in, calling, reference your local, "self" scope/object/underpants.
I mean, I really like self, and I find myself missing it learning Java-Fu.


June 28th, 2007 at 9:25 pm
I agree. There was a great post on the mailing list at one point I think called ‘When self is not self’ which dived into all these corner cases which would melt your mind if you didn’t have self. can’t find it right now for some reason. (Dealt with yield, generator classes, descriptors, properties, properties on meta classes, etc).
June 28th, 2007 at 9:51 pm
I’ve really come to love the explicit self, to the point that languages that don’t have it just feel creepy and wrong to me. Maybe that means I’ve been focused on Python for too long? Or maybe it means that Python is the best fit for me that I’ve found so far.
June 29th, 2007 at 12:03 am
I agree with you completely. “Self” is almost no different from “m_” ;)
June 29th, 2007 at 2:11 am
I don’t really like “self” (too much typing) so instead of “self” I just write “m”. That way, member values look like “m.value”, which is a lot like the m_value notation that people use in other languages.
June 29th, 2007 at 5:30 am
When I started python, I was coming from object pascal. I disliked self a lot. In object pascal, I liked using the “with” statement (no, it’s not like the current “with” in python).
Today, you’d have to pry explicit self from my cold dead hands :)
This guy only need to time to embrace python and stop trying to emulate his old language behavior in python.
June 29th, 2007 at 9:44 am
Explicit self is good specially if you make it a point of naming your member fields consistently. I code in VB.NET by day, and I always find that I want to use the same name as:
private field
public property
method parameter
class name
On top of that VB.NET is case insensitive, I always end up with a syntax like
private _field # carried over from Python! i did’t knew of the m_ convention when I started in VB.NET
public Property # looks matter in API design
method(pParameter) # So method parameters don’t shadow properties, f*ck implicit self!
uClassName # *u*ser class, maybe it is too ugly
VB.NET allows using “Me” (like C++’s “this”) when there is ambiguity, so I can say Me.Property,. That could let me drop the u from the class name and use the same convention for fileds and parameters, that way i can say:
Me._field
Me.Property
method(_parameter)
ClassName
But in practice is easy to forget the “Me.” because the compiler doesn’t enforce it and I haven’t found a way to make it complain when there is shadowing or ambiguity in local names. I wish VB.NET enforced “Me.”
On the other hand while I like explicit self and I like “self” better than “Me” or “this”, i wish self was a keyword, with similar semantics than javascrip’s “this”, that is, to refer to the outter namespace, wouldn’t that be sweet?