How to learn OO of python?

[could ildg]

I have learned python for over a month.
I heard that it was very easy to learn, but when I tried to know OO of python,
I found it really weird, some expressions seem very hard to understand,
and I can't find enough doc to know any more about it.
So, I wonder how did you master python? And where to find some cool docs?

Thanks.

[Bloke]

The best one I found was Dive Into Python - and it's free

http://www.diveintopython.org/

Also, How to Think Like a computer scientist - can't remember the link.

Bloke

[Pajo]

Here's the link for download:

http://ibiblio.org/obp/thinkCS/python.php

Bloke wrote:

The best one I found was Dive Into Python - and it's free

http://www.diveintopython.org/

Also, How to Think Like a computer scientist - can't remember the link.

Bloke

[Asbjørn Sæbø]

could ildg <co*******@gmai l.com> writes:

I have learned python for over a month.
I heard that it was very easy to learn, but when I tried to know OO of python,
I found it really weird, some expressions seem very hard to understand,
and I can't find enough doc to know any more about it.

Have you seen the python docs? Maybe this link is of some help.
http://www.python.org/doc/2.4.1/tut/node11.html

Asbjørn
--
Asbjørn Sæbø, post.doc.
Centre for Quantifiable Quality of Service in Communication Systems
Norwegian University of Science and Technology
<URL: http://www.q2s.ntnu.no/ >

[Peter Dembinski]

could ildg <co*******@gmai l.com> writes:

I have learned python for over a month.
I heard that it was very easy to learn, but when I tried to know OO
of python,
I found it really weird, some expressions seem very hard to understand,
and I can't find enough doc to know any more about it.
These may be hard to understand because you haven't understood OOP.
Python syntax is very similar to p-code used in computer science
books. Try to think like a computer scientist :>
So, I wonder how did you master python? And where to find some cool
docs?

Go to the nearest library and get some OO design book.

--
http://www.peter.dembinski.prv.pl

[Harlin Seritt]

I think I know what you mean. When I first started trying to learn the
OOP aspect of Python I thought it was strange since I had started with
OOP on Java and C++. Nonetheless, once you get the hang of it, OOP will
make way more sense than all of the complications of Java and C++ class
implementations . Let me give you a quick example of what I'm talking
about:

class Animal:
def eats(self):
print 'The animal eats.'
def walks(self):
print 'The animal walks.'

"""Here the class Dog instantiates the class Animal. 'Dog' will 'do'
whatever 'Animal' does plus some other things which we will describe in
this class code."""
class Dog(Animal):
"""#the self keyword means that this function will be a class
function"""
def communicate(sel f):
print 'The dog barks.'

"""# __init__ function defines what # #will happen as soon as this
class is instantiated. Also, the overloaded variable designators (color
= None, fur = None) allow the instantiator to optionally define these
variables when called from elsewhere."""

def __init__(self, color=None, fur=None):
"""# this time self will designate the variable 'color' # as a
class variable."""
self.color = color
self.fur = fur

if __name__ == '__main__':
sparky = Dog(color="Whit e", fur="Short")
sparky.communic ate()
print sparky.color
print sparky.fur
print sparky.eats() # Here sparky will access 'Animal' methods
that 'Dog' inherited.
print sparky.walks() # Another method originating from the 'Animal'
class.

What happens if you don't use 'self' inside your class code? You won't
be able to access it within the class outside of the method where you
initialized it. For instance, if you don't designate color with self
then you can only use the 'color' variable within the __init__()
method. This is useful whenever you want to use 'color' as a private
variable.

The same also goes for methods. Hopefully, you see how useful this can
be down the road. This way you won't have to use variable/method access
modifiers like Public, Private, Protected and so forth. If this doesn't
make sense or you want more clarity, please let me know.

Good luck,

Harlin Seritt

[Philippe C. Martin]

You might want to look at this first:

http://pigseye.kennesaw.edu/~dbraun/.../UML_tutorial/
http://uml.tutorials.trireme.com/


could ildg wrote:

I have learned python for over a month.
I heard that it was very easy to learn, but when I tried to know OO of
python, I found it really weird, some expressions seem very hard to
understand, and I can't find enough doc to know any more about it.
So, I wonder how did you master python? And where to find some cool docs?

Thanks.

[Philippe C. Martin]

PS: if you're under linux, try umbrello: you design your classes with a
graphical tool and umbrello will generate the code (Python too) for you.
Philippe C. Martin wrote:

You might want to look at this first:

http://pigseye.kennesaw.edu/~dbraun/.../UML_tutorial/
http://uml.tutorials.trireme.com/


could ildg wrote:

I have learned python for over a month.
I heard that it was very easy to learn, but when I tried to know OO of
python, I found it really weird, some expressions seem very hard to
understand, and I can't find enough doc to know any more about it.
So, I wonder how did you master python? And where to find some cool docs?

Thanks.

[Steven Bethard]

could ildg wrote:

I think decorator is a function which return a function, is this right?
e.g. The decorator below if from http://www.python.org/peps/pep-0318.html#id1.

def accepts(*types) :
def check_accepts(f ):
assert len(types) == f.func_code.co_ argcount
def new_f(*args, **kwds):
for (a, t) in zip(args, types):
assert isinstance(a, t), \
"arg %r does not match %s" % (a,t)
return f(*args, **kwds)
new_f.func_name = f.func_name
return new_f
return check_accepts

After I saw all the examples, I concluded that every decorator must
define an inner function which takes only one argument, the
function to decorate. Is this right?

It's close, but not quite right. (I will use the word "function" for
the moment, but see below for why this is inaccurate.) Every
*decorator* must take only one argument, the function to decorate. It is
not at all necessary that a decorator define an inner function.
Consider (from [1]):

def onexit(f):
import atexit
atexit.register (f)
return f

onexit is a decorator because it takes a function and returns a
function. In this case, it happens to be that the same function is
accepted and returned.

Note that in the 'accepts' example above, *check_accepts* is the
decorator, not accepts. The accepts function is actually a function
that *returns* decorators.

Now about that word "function". Decorators are actually *callables*
that accept a single *callable* and return a *callable*. Why does the
terminology matter? Because I can construct decorators from classes too
(from [2]):

class memoized(object ):
def __init__(self, func):
self.func = func
self.cache = {}
def __call__(self, *args):
try:
return self.cache[args]
except KeyError:
self.cache[args] = value = self.func(*args )
return value
except TypeError:
return self.func(*args )

Now the memoized decorator can be used just like any other decorator, e.g.:

@memoized
def fibonacci(n):
if n in (0, 1):
return n
return fibonacci(n-1) + fibonacci(n-2)

Note however that memoized is a *callable*, not a *function*.

STeVe

[1] http://www.python.org/peps/pep-0318.html
[2] http://wiki.python.org/moin/PythonDecoratorLibrary

[could ildg]

Steven Bethard:
Thank you so much!
Your answer is very very helpful~

On 5/19/05, Steven Bethard <st************ @gmail.com> wrote:

could ildg wrote:

I think decorator is a function which return a function, is this right?
e.g. The decorator below if from http://www.python.org/peps/pep-0318.html#id1.

def accepts(*types) :
def check_accepts(f ):
assert len(types) == f.func_code.co_ argcount
def new_f(*args, **kwds):
for (a, t) in zip(args, types):
assert isinstance(a, t), \
"arg %r does not match %s" % (a,t)
return f(*args, **kwds)
new_f.func_name = f.func_name
return new_f
return check_accepts

After I saw all the examples, I concluded that every decorator must
define an inner function which takes only one argument, the
function to decorate. Is this right?

It's close, but not quite right. (I will use the word "function" for
the moment, but see below for why this is inaccurate.) Every
*decorator* must take only one argument, the function to decorate. It is
not at all necessary that a decorator define an inner function.
Consider (from [1]):

def onexit(f):
import atexit
atexit.register (f)
return f

onexit is a decorator because it takes a function and returns a
function. In this case, it happens to be that the same function is
accepted and returned.

Note that in the 'accepts' example above, *check_accepts* is the
decorator, not accepts. The accepts function is actually a function
that *returns* decorators.

Now about that word "function". Decorators are actually *callables*
that accept a single *callable* and return a *callable*. Why does the
terminology matter? Because I can construct decorators from classes too
(from [2]):

class memoized(object ):
def __init__(self, func):
self.func = func
self.cache = {}
def __call__(self, *args):
try:
return self.cache[args]
except KeyError:
self.cache[args] = value = self.func(*args )
return value
except TypeError:
return self.func(*args )

Now the memoized decorator can be used just like any other decorator, e.g..:

@memoized
def fibonacci(n):
if n in (0, 1):
return n
return fibonacci(n-1) + fibonacci(n-2)

Note however that memoized is a *callable*, not a *function*.

STeVe

[1] http://www.python.org/peps/pep-0318.html
[2] http://wiki.python.org/moin/PythonDecoratorLibrary
--
http://mail.python.org/mailman/listinfo/python-list