Proposal for removing self

[Brent W. Hughes]

When doing object-oriented stuff, it bothers me to have to type "self" so
many times. I propose that Python allow the programmer to optionally type
".variable" instead of "self.variable" to mean the same thing. Of course,
the interpreter would have to be more careful about detecting floats that
begin with just a period as in ".5". What are your thoughts?

 

[Roger Binns]

When doing object-oriented stuff, it bothers me to have to type
"self" so many times. I propose that Python allow the programmer to
optionally type ".variable" instead of "self.variable" to mean the
same thing. Of course, the interpreter would have to be more careful
about detecting floats that begin with just a period as in ".5".
What are your thoughts?

When I started doing Python, it annoyed me. Now many years later
I definitely wouldn't change it. Guido has very good taste!

Roger

 

[Raymond Hettinger]

When doing object-oriented stuff, it bothers me to have to type "self" so
many times. I propose that Python allow the programmer to optionally type
".variable" instead of "self.variable" to mean the same thing. Of course,
the interpreter would have to be more careful about detecting floats that
begin with just a period as in ".5". What are your thoughts?

There's a FAQ on the subject:

http://www.python.org/doc/faq/gener...ed-explicitly-in-method-definitions-and-calls


Raymond Hettinger

 

[Raymond Hettinger]

When doing object-oriented stuff, it bothers me to have to type "self" so
many times. I propose that Python allow the programmer to optionally type
".variable" instead of "self.variable" to mean the same thing. Of course,
the interpreter would have to be more careful about detecting floats that
begin with just a period as in ".5". What are your thoughts?

There's a FAQ on the subject:

http://www.python.org/doc/faq/gener...ed-explicitly-in-method-definitions-and-calls


Raymond Hettinger

 

[Ravi Teja Bhupatiraju]

When doing object-oriented stuff, it bothers me to have to type "self" so
many times. I propose that Python allow the programmer to optionally type
".variable" instead of "self.variable" to mean the same thing. Of course,
the interpreter would have to be more careful about detecting floats that
begin with just a period as in ".5". What are your thoughts?

I know that this has been proposed before and am familiar with the
alternatives commonly suggested. I understand that most Python
programmers are happy with things the way they are in this respect.
But after 3 years of Python, somehow, I still keep forgetting to type
the darn thing. Of course, I always catch the omission quickly but
that makes me wish there was a better alternative. Python has
generally been about less typing and self seems somewhat contrary to
that.

This following is not a carefully thought one but I would be
interested to know what your opinions are. The following is inspired
by win32all.

<from Python COM docs>
class HelloWorld:
_public_methods_ = ['Hello']
_public_attrs_ = ['softspace', 'noCalls']
_readonly_attrs_ = ['noCalls']

def __init__(self):
pass
</from Python COM docs>

How about having an optional attribute for a class that negates the
requirement for self?

One advantage with this is I can see all the member variables in one
place. Great while reading code.

<sample>
class FooBar:
__public__ = [Name, Age]
def setName(name):
Name = name
</sample>

While I am complaining, a few other peeves ...

Another thing is I dislike is having to use __ for *every* private
variable. For *me* __private__ at the top of the class definition code
would be more elegant. __readonly__ would be another nicety.

Introducing the above attributes into the language would not likely
break any existing Python code.

Just my 2c.

 

[=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?=]

There was the "with" keyword :

with self:
.member = something
.member2 = .member3 + .member4

etc... it is a bit more implicit because of the "with"... anyway.

 

[Max M]

When doing object-oriented stuff, it bothers me to have to type "self" so
many times. I propose that Python allow the programmer to optionally type
".variable" instead of "self.variable" to mean the same thing. Of course,
the interpreter would have to be more careful about detecting floats that
begin with just a period as in ".5". What are your thoughts?

You don't have to use self. You could simply use underscore '_' instead.

class Person:

def setName(_, name):
_.name = name

def getName(_):
return _.name


But other Python programmers will hate you for it ;-)


If it is because you are using an attribute too many times inside a
method, a better solution is to map it to a local variable. It also has
the advantage of being faster.


class SoftwareProjectEstimator:

pi = 3.14

def guestimatePrice(self, hours, hour_price, developer_group_size):
pi = self.pi
guess = hours * pi
guess *= pi * developer_group_size
return guess * hour_price


regards Max M

 

[Alex Martelli]

I remember Alex Martelli advocating in our italian newsgroup on
C++ that C++ programmers should use "this->..." everywhere

I did that, and I did that before becoming mad with love for Python.

At the time my main job was helping hundreds of other programmers debug
their hairiest bugs (also helping them architect and design and test
things correctly, but debugging took far more time -- there's never time
to do it right so there's always time to do it over) and the lack of
this-> was a major cause of problems. confusions and bugs.

Seemed crazy to me at that time, but now after giving a try
to python I've to say that self-consciousness isn't bad.

If you write and debug truly complicated C++ templates you'll see why I
wanted explicit this-> prefixing most ardently...;-).


Alex

 

[Alex Martelli]

<sample>
class FooBar:
__public__ = [Name, Age]
def setName(name):
Name = name
</sample>

Go ahead: learn about metaclasses and bytecode hacking and write your
custom metaclass to perform this. Except for the little detail that
you'll never get away with not quoting 'Name' and 'Age' in the
__public__ assignment, the rest is reasonably easy to perform. Publish
your metaclass and start campaigning for it.

As long as you're just yakking about it ain't gonna happen -- become a
metaclass and bytecode expert and you can implement this in Python, or
convince somebody who is such an expert, for which the implementation
should be the job of a couple days tops.

While I am complaining, a few other peeves ...

Another thing is I dislike is having to use __ for *every* private
variable. For *me* __private__ at the top of the class definition code
would be more elegant. __readonly__ would be another nicety.

That's an even easier job for a custom metaclass with very modest amount
of byecode hacking. I suggest you start with this one, really truly
VERY easy. In fact you could probably do it without any actual hacking
on the bytecode itself, just rewriting a few tables of strings in the
code objects of the functions that are the methods of the class.

One impossible task (THAT would require hacking the Python parser and
changing things very deeply) as I already mentioned would be the form
you want for the assignment to __public__ (or similarly to
__private__etc). Those names are undefined (or worse defined globally)
and to teach Python (and human readers!) that for that one speclal case
of assignment to __public__ (or __private__), THAT one case only,
COMPLETELY different rules apply than ANYWHERE else in Python, well,
it's just as difficult as it is absurd.

I suggest you tackle the 'look ma no quotes!' task last, after
everything else is working, because that one detail is going to take far
longer than everything else put together, even if you're learning about
metaclasses and bytecodes from scratch.

Introducing the above attributes into the language would not likely
break any existing Python code.

If this peculiar behavior is limited to classes whose metaclass is your
custom RaviSpecial, "not likely" becomes "absolutely impossible", a
great enhancement. One more reason to implement this in a metaclass.

Just my 2c.

Well make it three cents and do an implementation, if you really care.
Otherwise, it's just words...


Alex

 

[Jacek Generowicz]

When doing object-oriented stuff, it bothers me to have to type "self" so
many times.

When doing object-oriented stuff, it makes me extactic to write
"self." in front of instance attributes. The knowledge that other
programmers are always doing the same, makes me even more happy.

The fact that there are plenty of C++ and Java coding conventions
which require that all class members' names start with "m_", or that
all instance attributes be accessed, in methods, via "this->" or
"this." (depending) on the language in question, seems to support
Python's choice in this matter.

I propose that Python allow the programmer to optionally type
".variable" instead of "self.variable" to mean the same thing. Of course,
the interpreter would have to be more careful about detecting floats that
begin with just a period as in ".5". What are your thoughts?

I think you should get into the habit of reading FAQs, Archives,
Googling (you know, the usual stuff), before making such suggestions
publically.

 

[Sion Arrowsmith]

You don't have to use self. You could simply use underscore '_' instead.

When I started using Python for developing my own bits and pieces I
got into the habit of using 'I' instead of 'self'. Means pretty much
the same thing, stands out better in code, takes up less space on a
line, and is two keystrokes shorter. ...

But other Python programmers will hate you for it ;-)

.... And then stopped when I got the job of maintaining other people's
Python code and writing stuff that other people would have to use, if
not actively maintain.

Going back to look at C++ code (whoever wrote it) makes me realise
how helpful it is to have an explicit marker as to what's belongs
to a class and what doesn't. And before anyone mentions Hungarian
notation, (a) is 'self.' *really* that much more of an imposition
over 'm_'? and (b) it's not useful for distinguishing methods from
functions.

 

[Ravi Teja Bhupatiraju]

<sample>
class FooBar:
__public__ = [Name, Age]
def setName(name):
Name = name
</sample>

Go ahead: learn about metaclasses and bytecode hacking and write your
custom metaclass to perform this. Except for the little detail that
you'll never get away with not quoting 'Name' and 'Age' in the
__public__ assignment, the rest is reasonably easy to perform. Publish
your metaclass and start campaigning for it.

As long as you're just yakking about it ain't gonna happen -- become a
metaclass and bytecode expert and you can implement this in Python, or
convince somebody who is such an expert, for which the implementation
should be the job of a couple days tops.

While I am complaining, a few other peeves ...

Another thing is I dislike is having to use __ for *every* private
variable. For *me* __private__ at the top of the class definition code
would be more elegant. __readonly__ would be another nicety.

That's an even easier job for a custom metaclass with very modest amount
of byecode hacking. I suggest you start with this one, really truly
VERY easy. In fact you could probably do it without any actual hacking
on the bytecode itself, just rewriting a few tables of strings in the
code objects of the functions that are the methods of the class.

One impossible task (THAT would require hacking the Python parser and
changing things very deeply) as I already mentioned would be the form
you want for the assignment to __public__ (or similarly to
__private__etc). Those names are undefined (or worse defined globally)
and to teach Python (and human readers!) that for that one speclal case
of assignment to __public__ (or __private__), THAT one case only,
COMPLETELY different rules apply than ANYWHERE else in Python, well,
it's just as difficult as it is absurd.

I suggest you tackle the 'look ma no quotes!' task last, after
everything else is working, because that one detail is going to take far
longer than everything else put together, even if you're learning about
metaclasses and bytecodes from scratch.

Introducing the above attributes into the language would not likely
break any existing Python code.

If this peculiar behavior is limited to classes whose metaclass is your
custom RaviSpecial, "not likely" becomes "absolutely impossible", a
great enhancement. One more reason to implement this in a metaclass.

Just my 2c.

Well make it three cents and do an implementation, if you really care.
Otherwise, it's just words...


Alex

Aren't you being a bit touchy Alex? Now I am glad that I did not
mention my wish list on properties and DBC . However, your post has
been quite informative. So I can live with that.

I wish I could rise up to your challenge and do all that stuff.
Regretfully, my Python skills don't extend to metaclasses and
especially "byte code hacking". Maybe you will explain those in your
next edition of the cookbook .

That said, I only could find one set of docs that could be called a
<tutorial> on metaclasses. Those were by David Mertz and Michele
Simionato. I could not get through them. I took comfort in the
statement "Metaclasses are deeper magic than 99% of users should ever
worry about" from the document. I am still looking for something I can
understand.

 

[Sean Ross]

__readonly__ would be another nicety.

Well, you could use this for __readonly__ (though I named it 'readable()'):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/157768

or if you want to use meta-classes (and this recipe does use __readonly__):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/197965

There are many similar implementations floating around.

As for removing self:
http://starship.python.net/crew/mwh/hacks/selfless.py

Enjoy,
Sean

 

[Alex Martelli]

Aren't you being a bit touchy Alex? Now I am glad that I did not
mention my wish list on properties and DBC . However, your post has
been quite informative. So I can live with that.

Exactly: far from being "touchy", I have been constructive. Coming back
to c.l.py after months of absence, and finding that, as usual, instead
of trying to use Python to best effect, people with mediocre Python
mastery keep trying to change Python (generally trying to break some of
the best aspects of it, because they don't understand enough Python to
see why they're good) was of course depressing -- I'm proud of myself
for reacting constructively rather than lashing out or going away again
at once.

I wish I could rise up to your challenge and do all that stuff.
Regretfully, my Python skills don't extend to metaclasses and
especially "byte code hacking". Maybe you will explain those in your
next edition of the cookbook .

Bytecodehacks are implementation-specific, and specific to one version
of Python (they wouldn't apply to Jython, IronPython, ...), so I'm not
going to write about them -- and you don't need to master them to try
out one of the changes you want, the __private__ idea. Metaclasses are
quite another issue: they are, even conceptually, absolutely fundamental
to understanding Python's object model, and if you do not understand the
object model, your knowledge of Python is shallow -- FAR too shallow for
you to _sensibly_ propose changes to Python, in my opinion.

So I did cover metaclasses in "Python in a Nutshell" as well as in
dedicated presentations (you can find the presentations' PDFs on the
usual site, www.strakt.com) and I will probably select a few metaclass
recipes for the second edition of the Cookbook.

That said, I only could find one set of docs that could be called a
<tutorial> on metaclasses. Those were by David Mertz and Michele
Simionato. I could not get through them. I took comfort in the
statement "Metaclasses are deeper magic than 99% of users should ever
worry about" from the document. I am still looking for something I can
understand.

At least 99% of users should not propose changes to Python. Many of
them would be well served by undersanding metaclasses, even if they
never need to write custom metaclasses -- they shouldn't _worry_ about
them, since there's nothing to worry about, but understanding and
worrying are different things. Which is why I cover metaclasses in
books, articles, posts (use google groups to look for my post that
mention metaclass, there were quite a few), and presentations.


Alex

 

[Ravi Teja Bhupatiraju]

Well, you could use this for __readonly__ (though I named it 'readable()'):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/157768

or if you want to use meta-classes (and this recipe does use __readonly__):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/197965

There are many similar implementations floating around.

As for removing self:
http://starship.python.net/crew/mwh/hacks/selfless.py

Enjoy,
Sean

Thanks Sean. This is interesting code. I should really learn about metaclasses.

 

[Alex Martelli]

Java's generics aren't nearly as liberal as C++ templates. They're basically
just syntax sugar for casting, so I doubt this would change much. I still
prefer the explicit "this." or "self.", mainly because it is a pattern that
I can use consistently across all of the languages I regularly program in
(JavaScript and ActionScript, like Python, make "this" mandatory as well).

Hmmm, yes, you have a point _in a multilanguage perspective_.
Unfortunately most programmers appear to dislike the concept of being
fluent across several languages.

That said, if an existing C++ or Java code base uses prefixes for all
instance variables, it's a bit redundant to add "this.". I have this
situation at my work, where I reluctantly have to make an exception to avoid
pissing people off.

Prefix naming is the norm, but I fail to see why 'member_foo' or
'my_foo' should be considered better than 'self.foo'. Sure, if you work
with an existing body of code it's generally better to follow its
conventions, otherwise your modifications stand out like a sore thumb.


Alex