Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Use empty string for self

Reply
Thread Tools

Use empty string for self

 
 
paullanier@gmail.com
Guest
Posts: n/a
 
      02-28-2006
It seems that lots of people don't like having to prefix self. in front
of instance variables when writing methods in Python. Of course,
whenever someone suggests doing away with 'self' many people point to
the scoping advantages that self brings. But I hadn't seen this
proposal when I searched so I thought I'd throw it out there. Maybe
it's already been thrown out but I like it.

The issue I have with self. is that is makes the code larger and more
complicated than it needs to be. Especially in math expressions like:
self.position[0] = self.startx + len(self.bitlist) * self.bitwidth

It really makes the code harder to read. On the other hand,
eliminating the self. would create other issues including readability
with regards to which vars are instance vars and which come from
somewhere else.

But what if we keep the '.' and leave out the self. Then the example
looks like:
..position[0] = .startx + len(.bitlist) * .bitwidth

The 'self' is implied but the scoping rules don't change and it's still
clear when reading it that they are instance variables. We can keep
the self in the method header (or not) but that is really a separate
issue.

Any comments? Has this been discussed before?

 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      03-01-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> It seems that lots of people don't like having to prefix self. in front

....
> But what if we keep the '.' and leave out the self.

....
> Any comments? Has this been discussed before?


Yes, at least once (found by group-googling for "removing self" in this
newsgroup):

http://groups.google.com/group/comp....791fdd4734579c


-Peter

 
Reply With Quote
 
 
 
 
paullanier@gmail.com
Guest
Posts: n/a
 
      03-01-2006
Thanks. I thought for sure it must have been discussed before but for
whatever reason, my googling skills couldn't locate it.

 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      03-01-2006
(E-Mail Removed) wrote:
> Any comments? Has this been discussed before?


Yes. To death. Executive summary: self is here to stay.
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      03-01-2006
Terry Hancock <(E-Mail Removed)> wrote:
> However, there is a slightly less onerous method which
> is perfectly legit in present Python -- just use "s"
> for "self":


This is being different for the sake of being different. Everybody *knows*
what self means. If you write your code with s instead of self, it just
makes it that much harder for other people to understand it.
 
Reply With Quote
 
Terry Hancock
Guest
Posts: n/a
 
      03-01-2006
On 28 Feb 2006 15:54:06 -0800
(E-Mail Removed) wrote:
> The issue I have with self. is that is makes the code
> larger and more complicated than it needs to be.
> Especially in math expressions like: self.position[0] =
> self.startx + len(self.bitlist) * self.bitwidth
>
> It really makes the code harder to read. On the other
> hand, eliminating the self. would create other issues
> including readability with regards to which vars are
> instance vars and which come from somewhere else.
>
> But what if we keep the '.' and leave out the self. Then
> the example looks like:
> .position[0] = .startx + len(.bitlist) * .bitwidth


I think I'm not the only person who hates this idea. The "."
is just too cryptic, IMHO. The main objection is that it
would require "magic" to make it work, though.

However, there is a slightly less onerous method which
is perfectly legit in present Python -- just use "s"
for "self":

def mymethod(s):
# ...
s.position[0] = s.startx + len(s.bitlist) * s.bitwidth
# ...

"self" is NOT a keyword, it's just a convention.

While I still generally prefer to see "self", I still
consider the above pretty readable, and it goes more than
halfway towards your goal.

Others have suggested "_" instead of "s". However, IMHO,
it's less visible, takes up the same space as "s", and
requires the shift key, so I'd rather just use "s".

And yes, it's been discussed to death on the list.

Cheers,
Terry


--
Terry Hancock ((E-Mail Removed))
Anansi Spaceworks http://www.AnansiSpaceworks.com

 
Reply With Quote
 
John Salerno
Guest
Posts: n/a
 
      03-01-2006
Roy Smith wrote:
> (E-Mail Removed) wrote:
>> Any comments? Has this been discussed before?

>
> Yes. To death. Executive summary: self is here to stay.


A related thing I was wondering about was the use of 'self' in class
methods as the first parameter. I understand that right now it is
necessary, but is this something that the language itself requires, or
just the way it is implemented now? It seems like a waste of typing to
always have to put self as the first parameter in every class method. Is
there no way for it to be implied?
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      03-01-2006
On 2006-03-01, John Salerno <(E-Mail Removed)> wrote:

>> Yes. To death. Executive summary: self is here to stay.

>
> A related thing I was wondering about was the use of 'self' in
> class methods as the first parameter.


It's not a related thing, it's the same thing.

> I understand that right now it is necessary, but is this
> something that the language itself requires,


Yes. Sort of. When declaring a function, you have to declare
all of the formal paramters. For functions that are bound to
class instances as methods, the first formal parameter is the
object instance. It's common practice to call that parameter
"self", but you can call it something else.

> or just the way it is implemented now?


No.

> It seems like a waste of typing


Typing is free. At least compared to the costs of the rest of
the life-cycle of a software project.

> to always have to put self as the first parameter in every
> class method.


You could call that first parameter to class methods "s" if you
can't afford the three extra letters (I've got lots of extra
letters, and I can send you some if you like). If you do call
it something other than self and somebody else ever has to
maintain your code, they'll be annoyed with you.

> Is there no way for it to be implied?


No.

--
Grant Edwards
(E-Mail Removed)
 
Reply With Quote
 
John Salerno
Guest
Posts: n/a
 
      03-01-2006
Grant Edwards wrote:

>> A related thing I was wondering about was the use of 'self' in
>> class methods as the first parameter.

>
> It's not a related thing, it's the same thing.


Oh sorry. I thought the OP was asking about having to use self when
qualifying attributes, or even if he was, I didn't realize it was the
same principle as my question. And just now I was reading about new
style classes, and it also seems like a bit of extra typing to have to
subclass object, but I guess that isn't something that can be implied
right now either.
 
Reply With Quote
 
James Stroud
Guest
Posts: n/a
 
      03-01-2006
John Salerno wrote:
> Grant Edwards wrote:
>
>>> A related thing I was wondering about was the use of 'self' in
>>> class methods as the first parameter.

>>
>>
>> It's not a related thing, it's the same thing.

>
>
> Oh sorry. I thought the OP was asking about having to use self when
> qualifying attributes, or even if he was, I didn't realize it was the
> same principle as my question. And just now I was reading about new
> style classes, and it also seems like a bit of extra typing to have to
> subclass object, but I guess that isn't something that can be implied
> right now either.


"self" is conceptually necessary. Notice the similarities between
doittoit() and It.doittoit():


py> def doittoit(it):
.... print it.whatzit
....
py> class It:
.... whatzit = 42
.... def doittoit(self):
.... print self.whatzit
....
py> anit = It()
py> doittoit(anit)
42
py> It.doittoit(anit)
42
py> anit.doittoit()
42


If you get this example, I'm pretty sure you will understand "self" and
its necessity.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Changing self: if self is a tree how to set to a different self Bart Kastermans Python 6 07-13-2008 11:19 AM
__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code) falcon Python 0 07-31-2005 05:41 PM
Re: __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code) Ralf W. Grosse-Kunstleve Python 2 07-12-2005 03:20 AM
Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code Ralf W. Grosse-Kunstleve Python 16 07-11-2005 09:28 PM
__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y;self.z=z boilerplate code) Ralf W. Grosse-Kunstleve Python 18 07-11-2005 04:01 PM



Advertisments