Proposal for removing self

13 views
Skip to first unread message

Brent W. Hughes

unread,
Aug 25, 2004, 6:01:24 PM8/25/04
to
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?


Batista, Facundo

unread,
Aug 25, 2004, 6:04:30 PM8/25/04
to Python-List (E-mail)
[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?

I type less than read, so I prefer the code to be better readable than
writable.

I'm -1 on your proposal.

. Facundo

Ian Sparks

unread,
Aug 25, 2004, 6:18:53 PM8/25/04
to Brent W. Hughes, pytho...@python.org
> begin with just a period as in ".5". What are your thoughts?

If you want to cut the typing down further you don't have to use "self" you can use :

class x:
def __init__(s,val):
s.val = val

def display(s):
print s.val

That's only one more character than your "." and it doesn't require any changes to Python.
Of course, you'd be breaking with the tradition of naming the instance as "self" but so would your magic "." method.

If you find yourself typing "self" a lot you can also do :

s = self
s.doSomething()

Sometimes python asks us to do things that are against our sensibilities (whitespace comes to mind) but once we try it for a while we find our knee-jerk reaction to change it was simply misplaced.

Live with the language a bit, use it a bit, give python the chance to change you before you try to change python.

Use python for a week or two more and see what I mean.


> -----Original Message-----
> From: Brent W. Hughes [mailto:brent....@comcast.net]
> Sent: Wednesday, August 25, 2004 6:01 PM
> To: pytho...@python.org
> Subject: Proposal for removing self
>
>
> 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?
>
>

> --
> http://mail.python.org/mailman/listinfo/python-list
>

Erik Max Francis

unread,
Aug 25, 2004, 6:38:52 PM8/25/04
to
"Batista, Facundo" wrote:

Furthermore, I believe there's been some talk as a prefixed dot being
reserved for possible use in a "with" control structure at some point in
the future. So using it to abbreviate self is definitely out.
(Besides, this proposal is not new.)

--
__ Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ You and I / We've seen it all / Chasing our hearts' desire
-- The Russian and Florence, _Chess_

Brett C.

unread,
Aug 25, 2004, 6:41:51 PM8/25/04
to
No thanks. This is a common suggestion and Guido has said it ain't
going to happen. I personally like 'self' a lot because ambiguity from
reading code goes away. It is easy to not see a '.' but not so for
'self.' . It also makes teaching OOP to people much easier since you
don't need to explain why some variables and method calls are to the
instance but other are not. "Explicit is better than implicit".

Roger Binns

unread,
Aug 25, 2004, 6:55:57 PM8/25/04
to

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

Roger


Ian J Cottee

unread,
Aug 25, 2004, 10:34:59 PM8/25/04
to
Erik Max Francis wrote:

> Furthermore, I believe there's been some talk as a prefixed dot being
> reserved for possible use in a "with" control structure at some point in
> the future. So using it to abbreviate self is definitely out.
> (Besides, this proposal is not new.)

Which means the op would be able to do

with self
.firstname = 'Brian'
.surname = 'Trubshaw'
.occupation = 'Test Pilot'
.ovine_experience = 'Unknown'

I guess

Ian

Aaron Rustad

unread,
Aug 25, 2004, 11:10:25 PM8/25/04
to

Raymond Hettinger

unread,
Aug 26, 2004, 1:19:14 AM8/26/04
to
"Brent W. Hughes" <brent....@comcast.net> wrote in message news:<T_7Xc.61360$Fg5.2281@attbi_s53>...

There's a FAQ on the subject:

http://www.python.org/doc/faq/general.html#why-must-self-be-used-explicitly-in-method-definitions-and-calls


Raymond Hettinger

Ishwar Rattan

unread,
Aug 26, 2004, 1:23:46 AM8/26/04
to
"Brett C." <br...@python.org> wrote in message news:<cgj4jf$1...@odak26.prod.google.com>...

I concur for keeping self intact, it does provide clarity in code writing
and reading.

-ishwar

Raymond Hettinger

unread,
Aug 26, 2004, 2:01:12 AM8/26/04
to
"Brent W. Hughes" <brent....@comcast.net> wrote in message news:<T_7Xc.61360$Fg5.2281@attbi_s53>...

There's a FAQ on the subject:

http://www.python.org/doc/faq/general.html#why-must-self-be-used-explicitly-in-method-definitions-and-calls


Raymond Hettinger

Andrea Griffini

unread,
Aug 26, 2004, 2:05:53 AM8/26/04
to
On 25 Aug 2004 22:23:46 -0700, rat...@cps.cmich.edu (Ishwar Rattan)
wrote:

>I concur for keeping self intact, it does provide clarity in code writing
>and reading.

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

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.

Andrea

Ravi Teja Bhupatiraju

unread,
Aug 26, 2004, 3:33:19 AM8/26/04
to
"Brent W. Hughes" <brent....@comcast.net> wrote in message news:<T_7Xc.61360$Fg5.2281@attbi_s53>...

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.

Pierre-Frédéric Caillaud

unread,
Aug 26, 2004, 7:53:25 AM8/26/04
to

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

unread,
Aug 26, 2004, 9:03:03 AM8/26/04
to


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

unread,
Aug 26, 2004, 9:10:38 AM8/26/04
to
Andrea Griffini <agr...@tin.it> wrote:

> On 25 Aug 2004 22:23:46 -0700, rat...@cps.cmich.edu (Ishwar Rattan)
> wrote:
>
> >I concur for keeping self intact, it does provide clarity in code writing
> >and reading.
>
> 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

unread,
Aug 26, 2004, 9:30:37 AM8/26/04
to
Ravi Teja Bhupatiraju <webra...@yahoo.com> wrote:
...

> <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

unread,
Aug 26, 2004, 11:01:34 AM8/26/04
to
"Brent W. Hughes" <brent....@comcast.net> writes:

> 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

unread,
Aug 26, 2004, 11:06:00 AM8/26/04
to
Max M <ma...@mxm.dk> wrote:
>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.

--
\S -- si...@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

Ravi Teja Bhupatiraju

unread,
Aug 26, 2004, 5:15:16 PM8/26/04
to
ale...@yahoo.com (Alex Martelli) wrote in message news:<1gj4sup.hrowbz1bzo06mN%ale...@yahoo.com>...

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

unread,
Aug 26, 2004, 6:54:38 PM8/26/04
to

"Ravi Teja Bhupatiraju" <webra...@yahoo.com> wrote in message

> __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


Delaney, Timothy C (Timothy)

unread,
Aug 26, 2004, 7:51:44 PM8/26/04
to pytho...@python.org
Andrea Griffini wrote:

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

I evangelise this here (mainly for Java code these days, but close
enough). Unfortunately, I don't seem to be able to convince anyone else
:(

Tim Delaney

Steven Bethard

unread,
Aug 27, 2004, 12:52:50 AM8/27/04
to pytho...@python.org
Delaney, Timothy C (Timothy <tdelaney <at> avaya.com> writes:
> I evangelise this here (mainly for Java code these days, but close
> enough). Unfortunately, I don't seem to be able to convince anyone else
> :(

I had to work in Java over the summer, and I started using 'this.' for all
instance variables. Found it much easier to read my code when I went back to
it later. (Of course, I was prompted by Python's syntax, but the real
motivator was reading someone else's code and having to hunt down their
instance variables to figure out what was going on...)

Steve


Alex Martelli

unread,
Aug 27, 2004, 2:35:43 AM8/27/04
to
Ravi Teja Bhupatiraju <webra...@yahoo.com> wrote:
...
> 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

Alex Martelli

unread,
Aug 27, 2004, 2:55:35 AM8/27/04
to

While it's also a good idea in Java, it's not as compelling as in C++,
because Java mostly lacks the complications due to C++'s templates and
freestanding ("not inside a class") names (haven't looked at Java
generics so I don't know if they got those complications back in;-).


Alex

Ravi Teja Bhupatiraju

unread,
Aug 27, 2004, 5:00:29 AM8/27/04
to
"Sean Ross" <sr...@connectmail.carleton.ca> wrote in message news:<gStXc.29013$DG.13...@news20.bellglobal.com>...

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

Robert Brewer

unread,
Aug 27, 2004, 9:16:37 AM8/27/04
to Alex Martelli, pytho...@python.org
Alex Martelli wrote:
> 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.

So are we, Alex. :) I, for one, am glad you're back! I always find your
commentary illuminating and engaging.


Robert Brewer
MIS
Amor Ministries
fuma...@amor.org

Dave Benjamin

unread,
Aug 27, 2004, 12:22:51 PM8/27/04
to

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).

I like it better, stylistically, because I feel like I can determine more
readily where things are coming from, but each language has its own scoping
rules (Java has no modules, for instance. I wonder how it works for inner
classes...) so I can't really make an argument across the board that
"this." / "self." is always better.

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. ;)

--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
"talking about music is like dancing about architecture."

Alex Martelli

unread,
Aug 27, 2004, 1:18:16 PM8/27/04
to Robert Brewer, pytho...@python.org

On 2004 Aug 27, at 15:16, Robert Brewer wrote:
...

> So are we, Alex. :) I, for one, am glad you're back! I always find your
> commentary illuminating and engaging.

Thanks! I appreciate your kudos. I'll steel myself to killfile the
bad guys rather than wasting my time repeating all the usual arguments
and ending up leaving c.l.py!-)


Alex

Alex Martelli

unread,
Aug 27, 2004, 1:37:43 PM8/27/04
to
Dave Benjamin <ra...@lackingtalent.com> wrote:
...

> > While it's also a good idea in Java, it's not as compelling as in C++,
> > because Java mostly lacks the complications due to C++'s templates and
> > freestanding ("not inside a class") names (haven't looked at Java
> > generics so I don't know if they got those complications back in;-).
>
> 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

Courageous

unread,
Sep 4, 2004, 11:20:05 AM9/4/04
to

>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.",

I prefer explicit self, but have often wished that it could disappear
syntactically as the first argument to methods. I've never seen a
really compelling reason for that.

C//

Reply all
Reply to author
Forward
0 new messages