Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > understanding self

Reply
Thread Tools

understanding self

 
 
bruce stockwell
Guest
Posts: n/a
 
      07-07-2004
Using 'self' in classes seems pretty straight forward. My curiosity is
why I have to use it. Shouldn't it be implied? If I create an instance
of 'human' called 'bruce' and call the method 'blink' why do I have to
pass bruce into the method e.g.

class human:
...code
def blink(self,times):
for i in range(times):
if self.eye_is_closed:
self.eye_open()
self.eye_close()
else:
self.eye_close()
self.eye_open()
def eye_open(self):
...code
def eye_close(self):
...code


bruce = human()
bruce.blink(5)

blink is a method of bruce because bruce is an instance of human.
Reading this silly code I can understand what is going on if self was
not included. Can anyone enlighten me as to why we have self?

by the way..six months of python and I'm 10 times the programmer I was
with vb


v/r
Bruce
 
Reply With Quote
 
 
 
 
Jeff Shannon
Guest
Posts: n/a
 
      07-08-2004
bruce stockwell wrote:

>Using 'self' in classes seems pretty straight forward. My curiosity is
>why I have to use it. Shouldn't it be implied?
>


The problem is that an implied 'self' is harder to read than an explicit
'self', and also opens the door for ambiguity when an instance attribute
has the same name as a global or builtin attribute.

Let's look at an example in a hypothetical Python variant where 'self'
is implied --

class eye:
def open(which):
# do stuff here

def close(which):
# do stuff here

def blink(which):
if closed:
open(which)
close(which)
else:
close(which)
open(which)

e = eye()
e.blink('right')

But wait -- open() is an obsolete built-in function for opening a file.
Which should eye.blink() do -- open and close the right eye, or open a
file with the name of 'right' ?? If it's the former, then what do you
do if you *want* to open that file? If it's the latter, then what
happens when the next version of Python comes along and open() has been
removed from built-ins?

Even without these namespace conflicts, it's difficult when you're
reading a long method and see a call to "make_thingumbob()" -- where do
you look to see what that does? It might be another method of that
class, or it might be a global (or even built-in) function. It then
requires extra thought and search-time to figure out the intent.

One of the design principles of Python is that ease of *reading* is more
important than ease of *writing*. It's worth a few extra keystrokes if
it will save you a second or two of time when reading unfamiliar code --
because most code is only written once, but read *many* times.

Jeff Shannon
Technician/Programmer
Credit International

 
Reply With Quote
 
 
 
 
Ville Vainio
Guest
Posts: n/a
 
      07-08-2004
>>>>> "Jeff" == Jeff Shannon <(E-Mail Removed)> writes:

Jeff> But wait -- open() is an obsolete built-in function for
Jeff> opening a file. Which should eye.blink() do -- open and
Jeff> close the right eye, or

I'll just like to point out that open() is in no way obsolete, even if
it's aliased to "file". ItÃ's probably intop 5% of builtins in terms
of frequency in existing code, so deprecating it would deprecate
pretty much all the existing python code.

IÃ'm sure äll see "print" being deprecated before "open".

--
Ville Vainio http://tinyurl.com/2prnb
 
Reply With Quote
 
Jeff Shannon
Guest
Posts: n/a
 
      07-08-2004
Ville Vainio wrote:

>>>>>>"Jeff" == Jeff Shannon <(E-Mail Removed)> writes:
>>>>>>
>>>>>>

>
> Jeff> But wait -- open() is an obsolete built-in function for
> Jeff> opening a file. Which should eye.blink() do -- open and
> Jeff> close the right eye, or
>
>I'll just like to point out that open() is in no way obsolete, even if
>it's aliased to "file". ItÃ's probably intop 5% of builtins in terms
>of frequency in existing code, so deprecating it would deprecate
>pretty much all the existing python code.
>
>IÃ'm sure äll see "print" being deprecated before "open".
>
>


Okay, perhaps "legacy" is a better term than "obsolete". In either
case, it's recommended that it not be used in new code, even if there is
no current plan to remove it. Not that the specifics of this case are
particularly germane to the point I was making...

Jeff Shannon
Technician/Programmer
Credit International

 
Reply With Quote
 
Greg Ewing
Guest
Posts: n/a
 
      07-08-2004
Jeff Shannon wrote:
> Okay, perhaps "legacy" is a better term than "obsolete". In either
> case, it's recommended that it not be used in new code


In a recent exchange on python-dev, Guido has made it clear
that this is NOT the case -- he wants people to continue
using open(), since it might not remain a synonym for
file() in the future. He has acknowledged that the
documentation needs clarification on this.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      07-08-2004
On Thu, 08 Jul 2004 16:00:43 +1200, Greg Ewing
<(E-Mail Removed)> declaimed the following in
comp.lang.python:

> In a recent exchange on python-dev, Guido has made it clear
> that this is NOT the case -- he wants people to continue
> using open(), since it might not remain a synonym for
> file() in the future. He has acknowledged that the
> documentation needs clarification on this.


Now there is a scary thought... one or the other will
incorporate the functions of anydbm, and a few other file specific
modules -- attempting to determine what is needed to process any file
found on a system.

--
> ================================================== ============ <
> http://www.velocityreviews.com/forums/(E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> (E-Mail Removed) | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

 
Reply With Quote
 
David Fraser
Guest
Posts: n/a
 
      07-08-2004
Jeff Shannon wrote:
> bruce stockwell wrote:
>
>> Using 'self' in classes seems pretty straight forward. My curiosity is
>> why I have to use it. Shouldn't it be implied?

>
>
> The problem is that an implied 'self' is harder to read than an explicit
> 'self', and also opens the door for ambiguity when an instance attribute
> has the same name as a global or builtin attribute.
>
> Let's look at an example in a hypothetical Python variant where 'self'
> is implied --
>
> class eye:
> def open(which):
> # do stuff here
>
> def close(which):
> # do stuff here
>
> def blink(which):
> if closed:
> open(which)
> close(which)
> else:
> close(which)
> open(which)
>
> e = eye()
> e.blink('right')
>
> But wait -- open() is an obsolete built-in function for opening a file.
> Which should eye.blink() do -- open and close the right eye, or open a
> file with the name of 'right' ?? If it's the former, then what do you
> do if you *want* to open that file? If it's the latter, then what
> happens when the next version of Python comes along and open() has been
> removed from built-ins?
>
> Even without these namespace conflicts, it's difficult when you're
> reading a long method and see a call to "make_thingumbob()" -- where do
> you look to see what that does? It might be another method of that
> class, or it might be a global (or even built-in) function. It then
> requires extra thought and search-time to figure out the intent.
>
> One of the design principles of Python is that ease of *reading* is more
> important than ease of *writing*. It's worth a few extra keystrokes if
> it will save you a second or two of time when reading unfamiliar code --
> because most code is only written once, but read *many* times.


You are assuming here that "self." would be implied on potential
attribute accesses (like this in C++). The reason this is problematic is
that it complicates Python's scoping structured. But it is not
neccessarily the only way that having an implicit self could be used -
self could be implicit in the parameter list, but explicit for any other
use.

For example, there could be a keyword 'method' which defines a method
object that takes self as its first parameter even though it's not
declared. So the two __cmp__ definitions below would be equivalent:

class Complex:
# ...
def cmpabs(self, other):
return self.abs().__cmp__(other.abs())
method cmpabs2(other):
return self.abs().__cmp__(other.abs())

a = Complex(3,4)
b = Complex(4,3)
print a.cmpabs(b)
print a.cmpabs2(b)

David
 
Reply With Quote
 
Albert Hofkamp
Guest
Posts: n/a
 
      07-08-2004
On Wed, 7 Jul 2004 19:24:14 -0400, bruce stockwell <(E-Mail Removed)> wrote:
> blink is a method of bruce because bruce is an instance of human.
> Reading this silly code I can understand what is going on if self was
> not included. Can anyone enlighten me as to why we have self?


ok, what about this?

def f():
# do something
return 5

class X:
def f(self):
# do something else
return 4


def doit(self):
x=self.f()
y=f()

The example is very silly, but when executing doit(), it is clear that x
will contain 4 and y will contain 5 afterwards.

Now if we drop self, we get

def doit(self):
x=f()
y=f()

Now there is no difference between both calls any more. That means that
the computer does not understand that you are aiming for calling
different functions f() here. We can agree that f() means the f in the
class, but then I cannot reach the global f any more, or vice versa. In
both cases, I lose expressiveness.


Albert
--
Unlike popular belief, the .doc format is not an open publically available format.
 
Reply With Quote
 
Colin J. Williams
Guest
Posts: n/a
 
      07-08-2004


Jeff Shannon wrote:
> bruce stockwell wrote:
>
>> Using 'self' in classes seems pretty straight forward. My curiosity is
>> why I have to use it. Shouldn't it be implied?

>
>
> The problem is that an implied 'self' is harder to read than an explicit
> 'self', and also opens the door for ambiguity when an instance attribute
> has the same name as a global or builtin attribute.
>
> Let's look at an example in a hypothetical Python variant where 'self'
> is implied --
>
> class eye:
> def open(which):
> # do stuff here
>
> def close(which):
> # do stuff here
>
> def blink(which):
> if closed:
> open(which)
> close(which)
> else:
> close(which)
> open(which)
>
> e = eye()
> e.blink('right')
>
> But wait -- open() is an obsolete built-in function for opening a file.
> Which should eye.blink() do -- open and close the right eye, or open a
> file with the name of 'right' ?? If it's the former, then what do you
> do if you *want* to open that file? If it's the latter, then what
> happens when the next version of Python comes along and open() has been
> removed from built-ins?
>
> Even without these namespace conflicts, it's difficult when you're
> reading a long method and see a call to "make_thingumbob()" -- where do
> you look to see what that does? It might be another method of that
> class, or it might be a global (or even built-in) function. It then
> requires extra thought and search-time to figure out the intent.
>
> One of the design principles of Python is that ease of *reading* is more
> important than ease of *writing*. It's worth a few extra keystrokes if
> it will save you a second or two of time when reading unfamiliar code --
> because most code is only written once, but read *many* times.
>
> Jeff Shannon
> Technician/Programmer
> Credit International
>

I'm sure this issue has been flogged before.

Couldn't both clarity and simplicity be achieved by replacing the
"self." with ".". self is not normally at the left of an assignment and
the self would not need to appear in the method signature.

Version 3 pehaps?

Colin W.

 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      07-08-2004
In article <ccirf5$51j$(E-Mail Removed)>,
David Fraser <(E-Mail Removed)> wrote:

> For example, there could be a keyword 'method' which defines a method
> object that takes self as its first parameter even though it's not
> declared. So the two __cmp__ definitions below would be equivalent:
>
> class Complex:
> # ...
> def cmpabs(self, other):
> return self.abs().__cmp__(other.abs())
> method cmpabs2(other):
> return self.abs().__cmp__(other.abs())


Yes, you are right, you could design things to work that way. But why
would you want to? Having two ways to do the same thing just adds
complexity without adding my value.

People learning the language have to learn two different things. Some
people will adopt one style, and some will adopt the other. As a
result, we would have two different bodies of code floating around.
You'd end up with things like this:

1) Pythonista A has adopted the "explicit self" style, and convinces his
friend to learn the language. He teaches the "explicit self" style to
his friend.

2) The friend is happy with the new language and goes out into the world
confident that he's added a new and useful skill to his portfolio.

3) The friend picks up a piece of code written by pythonista B, who has
adopted the "implicit self" style, and discovers that he can't make
heads or tails of it.

4) The friend changes his mind about Python, saying, "Gee, if I wanted a
language in which there's more than one way to do it, I would have stuck
with Perl".

5) The Python world has lost another potential convert, ultimately
hastening the end of all intelligent life as we know it.
 
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