Trying to understand Python objects

[walterbyrd]

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.

1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

2) Are classes typically created like this:

class Point:
pass

Then attributes are added at some other time?

3) What is with the __underscores__ ??

4) Are parameters passed to an class definition?

class Whatever(params ):
pass

I sort-of understand the way objects work with PHP. With PHP, the
classes are defined in one place - sort of like a function. To me, that
makes more sense.

[John Henry]

Re: Trying to understand Python objects

classes are not functions. They are a "thing".

A simple example:

class pet(object):

def __init__(self):
self.myLegs=sel f._SetNumberOfL egs()

def _SetNumberOfLeg s(self):
return 0

def HowManyLegsDoYo uHave(self):
print self.myLegs

class cat(pet):

def _SetNumberOfLeg s(self):
return 4

class rabbit(pet):

def _SetNumberOfLeg s(self):
return 2

class fish(pet):
pass

myPets=[cat(), fish(), rabbit()]

for pet in myPets:
pet.HowManyLegs DoYouHave()


In the above example, both cat and rabbit has legs and fish? Not
normally. :=)

walterbyrd wrote:

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.
>
1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?
>
2) Are classes typically created like this:
>
class Point:
pass
>
Then attributes are added at some other time?
>
3) What is with the __underscores__ ??
>
4) Are parameters passed to an class definition?
>
class Whatever(params ):
pass
>
I sort-of understand the way objects work with PHP. With PHP, the
classes are defined in one place - sort of like a function. To me, that
makes more sense.

[Gabriel Genellina]

Re: Trying to understand Python objects

At Tuesday 21/11/2006 20:03, walterbyrd wrote:

>1) Can attributes can added just anywhere? I create an object called
>point, then I can add attributes any time, and at any place in the
>program?

For "normal" python objects, yes, you can add/delete any attribute,
anytime, anywhere. There are hooks where you can actively deny
attribute creation, or "freeze" the attribute list, but these are
considered advanced usage.

>2) Are classes typically created like this:
>
>class Point:
pass
>
>Then attributes are added at some other time?

Not "typically" ! Although you *can* do that, doesn't mean that you
*must* do things that way.
A 2D point might say:

class Point2D(object) :
def __init__(self, x, y):
self.x = x
self.y = y

def distance(self, other):
return math.hypot(othe r.x-self.x, other.y-self.y)

p0 = Point2D(3, 2)
p1 = Point2D(0, 6)
p0.distance(p1) # gives 5

>3) What is with the __underscores__ ??

Names that begin and end in __ are used by Python itself and have
some "magic" attached sometimes. The most common is __init__ (used to
initialize a new instance). __str__ by example, is used to get an
object's textual representation suitable for printing. If you execute

>>print p0

using the example above, you'll get something like <Point2D instance
at 0x12345678>. Add the following to the Point2D class and you get a nice pair:

def __str__(self):
return '(%f, %f)' % (self.x, self.y)

>4) Are parameters passed to an class definition?
>
>class Whatever(params ):
pass

If you see something like that, "params" are not parameters, but base
classes. The Whatever class inherits all attributes and methods known
to its bases, and may provide its own.

>I sort-of understand the way objects work with PHP. With PHP, the
>classes are defined in one place - sort of like a function. To me, that
>makes more sense.

Usually in Python you also define a class in only one place - you
*can* modify it later, and that's a powerful feature, but certainly
you don't have to!


--
Gabriel Genellina
Softlab SRL

_______________ _______________ _______________ _____
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

[James Stroud]

Re: Trying to understand Python objects

walterbyrd wrote:

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.
>
1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

Not all objects behave this way. For example, incidences of the object
class:

pyj = object()
pyj.att = 2
------------------------------------------------------------
Traceback (most recent call last):
File "<ipython console>", line 1, in <module>
<type 'exceptions.Att ributeError'>: 'object' object has no attribute 'att'

Strangely enough, the exact rule is difficult to infer from the behavior
of cPython:

pydef doit():
.... pass
....
pydoit.att = 2
pydoit.att
2
pytype(j)
<type 'object'>
pytype(doit)
<type 'function'>

Instances of your own classes and the classes you define yourself behave
as you describe, though:

pyclass C: pass
....
pyC.classatt = 2
pyC.classatt
2
pyc = C()
pyc.instat = 5
pyc.instat
5

2) Are classes typically created like this:
>
class Point:
pass

Its better for classes to descend from object, actually:

pyclass Point(object): pass
....
pytype(Point)
<type 'type'>
pytype(C)
<type 'classobj'>

'type' type classes behave correctly with certain language features,
such as properties. Last I checked 'classobj' classes do not. So
new-style ('type' type) classes are preferred.

Then attributes are added at some other time?

Yes. This goes for old (clasobj) and new style classes.

3) What is with the __underscores__ ??

They are hard to look at, but they are meant to signify implementation
specific attributes of objects and not interface specific attributes.
But, in my opinion, a lot of python code, especially "higher-level" code
blurs the distinction, so it becomes a little underscore heavy.

4) Are parameters passed to an class definition?
>
class Whatever(params ):
pass

No.

This is done under the implementation specific method called "__init__".

pyclass D(object):
.... def __init__(self, param1, param2):
.... self.a = param1
.... self.b = param2
....
pyd = D(2,5)
pyd.a
2
pyd.b
5

I sort-of understand the way objects work with PHP. With PHP, the
classes are defined in one place - sort of like a function. To me, that
makes more sense.

The difference (and I don't know PHP) is that many of the objects you
create (classes and instances of those classes) are "mutable". Which
means, of course that you can change them. I've found that good
programming practice requires less of this mutability in general (i.e.
adding attributes on the fly), but it is there if you need it. I think
this flexibility is part the python philosophy, but I am not a python
philosopher (nor was I meant to be).

James


--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

[George Sakkis]

Re: Trying to understand Python objects

walterbyrd wrote:

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.
>
1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

For user-defined (i.e. not builtin) classes, yes. There are ways to
prevent this (or at least it make it harder), but they're usually not
worth it unless you have pretty good reasons to do it. And just in case
you're wondering, "that's how php/c++/java/whatever does it" doesn't
count as a pretty good reason.

2) Are classes typically created like this:
>
class Point:
pass
>
Then attributes are added at some other time?

Yes, you can do it. No, it is not typical. The typical is to initialize
all class attributes in the class body, and all instance attributes in
__init__:

class Point(object): # prefer new-style classes in new code
num_instances = 0 # a class attribute

def __init__(self, x, y):
self.x, self.y = x,y # instance attributes

There are cases where this is not possible or desirable; Python doesn't
get in your way in these cases, but they are certainly not typical.

3) What is with the __underscores__ ??

They're special attributes, usually methods that perform "operator
overloading". If the term doesn't mean anything to you, think of it as
a method that is called implicitly by a specific operator. E.g. instead
of having a normal method add() and then call it as a.add(b), you can
define the special method __add__ and have it called when you write a +
b. There are several details I left out but that's the gist of it.

4) Are parameters passed to an class definition?
>
class Whatever(params ):
pass

No, these are not parameters, they are the base (aka "super") clasess
of Whatever.

I sort-of understand the way objects work with PHP. With PHP, the
classes are defined in one place - sort of like a function. To me, that
makes more sense.

It makes sense in Python too, see point (2). The difference is that for
the few cases that it either doesn't make sense or it's less convenient
or desirable, Python doesn't get in your way.

HTH,
George

[Ben Finney]

Re: Trying to understand Python objects

"walterbyrd " <walterbyrd@ina me.comwrites:

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.

Congratulations for taking the effort to figure it out, and for
thinking about the questions you want answered.

1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

Generally, yes. It's up to the programmer to do so in a way that's
readable and makes sense to later readers. There are conventions, of
course, and you should ask about anything specific that confuses you.

One convention that you seem to be unaware of is that assigning
attributes outside of the class's methods is unusual. This is only a
convention, though, and not enforced by the language; on the uncommon
occasions you need to add attributes to an instance outside that
class's methods, you're not prevented from doing it.

2) Are classes typically created like this:
>
class Point:
pass

Typically, classes are created as a subclass of another class. The
top-level basic type in Python is 'object', so if your class doesn't
make sense deriving from anything else, derive from 'object'.

class Point(object):
pass

Defining a class with *no* superclass is not recommended. If you don't
yet understand the difference between the above style (called a
"new-style" class) and the style you presented, you should always
derive from a superclass ('object' or something more specific) until
you encounter a situation where that causes a problem.

Then attributes are added at some other time?

No. Typically, the desired attributes are added either to the class
when it is defined, resulting in an attribute value that is shared by
all instances of that class::

class Point(object):
spam = 4

Or, the attributes are added to a specific instance (often in the
initialisation method) so that each instance has a separate attribute
with the same name::

class Point(object):
spam = 4
def __init__(self):
eggs = 2

3) What is with the __underscores__ ??

Another convention. Names of the form '__foo__' are a signal to the
reader that this name will be treated specially; often the internals
of Python syntax or some builtin type will look for those names when
performing behind-the-scenes magic.

For instance, the '__init__' attribute of a class is expected to be a
function, and that function is called by Python's instance creation
steps immediately after the creation of an instance. Thus, it is used
to "initialise " the newly-created instance of the class, doing things
specific to that instance.

4) Are parameters passed to an class definition?
>
class Whatever(params ):
pass

The parameters of the class definition are the super-classes from
which this class should inherit its attributes. They don't correspond
with the parameters to the class constructor.

When you create a new instance of a class, its constructor is called
to create the new instance, and then the initialiser is called, to
perform post-creation steps on the new instance. This all occurs in
one step, as far as the code that called the constructor is concerned.

Unlike in many other languages, you will rarely need to define a
constructor ('__new__') for your Python classes. It's far more common
to let the default constructor create the object, and have any
initialisation steps on the newly-created instance performed in the
class '__init__' method.

The __init__ method gets called by Python's internals (hence the
"special" name with underscores) immediately after the creation of the
instance. It is called with parameters consisting of the newly-created
instance object, followed by all the parameters that were passed to
the constructor.

origin = Point(0, 0)

This will call the constructor of the Point class, which will create a
new instance; then, the __init__ method of the Point class will be
called with the parameters (<new Point instance>, 0, 0). This means
the function has access to the specific instance, and can modify it
accordingly.

The convention is to use 'self' as the name to refer to the first
parameter to instance methods, so that the instance object is referred
to by the parameter name 'self' in that method.

class Point(object):
spam = 4
def __init__(self, x_coord, y_coord):
if x_coord < 0:
x_coord = 0
if y_coord < 0:
y_coord = 0
self.x = x_coord
self.y = y_coord

This initialisation method does a bit of value fudging, then assigns
values to attributes of the instance, named 'self' in the context of
the method.

After the constructor and the __init__ method have finished, the
program continues at the point where the constructor was called. Thus,
the attributes assigned to the instance are immediately available::

origin = Point(0, 0)
print origin.x

--
\ "Anyone who believes exponential growth can go on forever in a |
`\ finite world is either a madman or an economist." -- Kenneth |
_o__) Boulding |
Ben Finney

[George Sakkis]

Re: Trying to understand Python objects

James Stroud wrote:

walterbyrd wrote:

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.

1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

>
Not all objects behave this way. For example, incidences of the object
class:
>
(snipped)
>

Then attributes are added at some other time?

>
Yes. This goes for old (clasobj) and new style classes.
>
(snipped)
>
>I think this flexibility is part the python philosophy, but I am not a python
philosopher (nor was I meant to be).

Neither a python tutor, apparently, but strong candidate for the
monthly "most confusing-to-a-newbie reply" award.

George

[Ben Finney]

Re: Trying to understand Python objects

Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:

Or, the attributes are added to a specific instance (often in the
initialisation method) so that each instance has a separate attribute
with the same name::

The example here should have been::

class Point(object):
spam = 4
def __init__(self):
self.eggs = 2

--
\ "For mad scientists who keep brains in jars, here's a tip: why |
`\ not add a slice of lemon to each jar, for freshness?" -- Jack |
_o__) Handey |
Ben Finney

[Robert Kern]

Re: Trying to understand Python objects

Ben Finney wrote:

Or, the attributes are added to a specific instance (often in the
initialisation method) so that each instance has a separate attribute
with the same name::
>
class Point(object):
spam = 4
def __init__(self):
eggs = 2

There's a typo there. For the sake of not confusing the OP, this is correct:

class Point(object):
spam = 4
def __init__(self):
self.eggs = 2


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Fredrik Lundh]

Re: Trying to understand Python objects

walterbyrd wrote:

1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

in general, yes, but that should be done sparingly.

2) Are classes typically created like this:
>
class Point:
pass
>
Then attributes are added at some other time?

no, classes with attributes are typically created like this:

class Point:
def __init__(self, x, y):
self.x = x
self.y = y

p = Point(1, 2)

i.e. attributes are created in the initialization function.

3) What is with the __underscores__ ??

they're reserved for use by the interpreter, usually for calling special
methods in you class:

http://effbot.org/pyref/reserved-identifier-classes

http://effbot.org/pyref/special-method-names

4) Are parameters passed to an class definition?
>
class Whatever(params ):
pass

no, that's the syntax used for inheritance. arguments passed to the
class constructor are passed on to the initialization function (see the
example above).

for more on this, see the tutorial. Jay Parlar's gentle introduction
from the community tutorial might be helpful:

http://effbot.org/pytut/node11-baseline.htm

</F>

[Bruno Desthuilliers]

Re: Trying to understand Python objects

walterbyrd wrote:

Reading "Think Like a Computer Scientist" I am not sure I understand
the way it describes the way objects work with Python.
>
1) Can attributes can added just anywhere? I create an object called
point, then I can add attributes any time, and at any place in the
program?

Apart from a few special cases (mainly builtin types or new-style
classes using slots IIRC), yes.

Now wether this is a good idea is another question. As far as I'm
concerned, I do use this feature, but only for special cases, and almost
only in metaclasses or other special 2-stages init.

2) Are classes typically created like this:
>
class Point:
pass
>
Then attributes are added at some other time?

Nope. The canonical idiom is to use the initializer:

class Point(object):
def __init__(self, attr1, attr2):
self.attr1 = attr1
self.attr2 = attr2
self.attr3 = 42

3) What is with the __underscores__ ??

"magic" methods or attributes. The initializer ('__init__') is one of
them, which is called at instance creation time. Most of the magic
__methods__ are used to implement or override operators. You'll find the
relevant documentation around here:

http://docs.python.org/ref/specialnames.html

4) Are parameters passed to an class definition?
>
class Whatever(params ):
pass

A class statement is not a function definition statement. Here, you ask
for a class Whatever inheriting from class params. Cf the above point
about the __init__ method for passing args at instanciation.

I sort-of understand the way objects work with PHP. With PHP, the
classes are defined in one place - sort of like a function.

FWIW, Python's classes actually are callable objects (just like
functions are callable objects). To instanciate a class, you just call
the class, no 'new' keyword needed.

To me, that
makes more sense.

<?php

class Obj {
// pass
}

$obj = new Obj();
$obj->name = "toto";
echo $obj->name;

?>

Just like Python (and Javascript FWIW), PHP objects are mostly hashtable
in disguise. But - having some experience with both PHP and Python (and
some other OOPLs), I can tell you that Python's object model is far
superior to PHP's one.

The only "gotcha" here wrt/ most other object models is that attributes
defined in the class statement body (ie, outside methods) are attached
to the class object itself (and then shared by all instances of the
class), not to instances themselves. Instance attributes initialisation
is usually done in the __init__(self, ...) method.

HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[walterbyrd]

Re: Trying to understand Python objects

Thanks everybody. I will sort all of this out, but right now my head is
spinning.

Is there some book, or other reference, that explains of this? I was
thinking about "Python for Dummies." The "Think like a Computer
Scientist" book, and "Dive into Python" book don't seem to explain
Python's object model clearly enough for me.

[Ben Finney]

Re: Trying to understand Python objects

"walterbyrd " <walterbyrd@ina me.comwrites:

Is there some book, or other reference, that explains of this? I was
thinking about "Python for Dummies." The "Think like a Computer
Scientist" book, and "Dive into Python" book don't seem to explain
Python's object model clearly enough for me.

The canonical introduction is the Python tutorial::

<URL:http://docs.python.org/tut/>

To get benefit from this, you should *work through* this document, not
merely read it. Do each exercise and don't go on until you believe you
understand what it's doing.

--
\ "When I turned two I was really anxious, because I'd doubled my |
`\ age in a year. I thought, if this keeps up, by the time I'm six |
_o__) I'll be ninety." -- Steven Wright |
Ben Finney

[Aahz]

Re: Trying to understand Python objects

In article <mailman.564.11 64158130.32031. python-list@python.org >,
Ben Finney <bignose+hate s-spam@benfinney. id.auwrote:

>
>Typically, classes are created as a subclass of another class. The
>top-level basic type in Python is 'object', so if your class doesn't
>make sense deriving from anything else, derive from 'object'.
>
class Point(object):
pass
>
>Defining a class with *no* superclass is not recommended. If you don't
>yet understand the difference between the above style (called a
>"new-style" class) and the style you presented, you should always
>derive from a superclass ('object' or something more specific) until
>you encounter a situation where that causes a problem.

Side note: I disagree with the above advice, but it's Thanksgiving and I
don't have enough room on the margin for the proof. I think classic
classes are just fine.
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"In many ways, it's a dull language, borrowing solid old concepts from
many other languages & styles: boring syntax, unsurprising semantics,
few automatic coercions, etc etc. But that's one of the things I like
about it." --Tim Peters on Python, 16 Sep 1993

[Aahz]

Re: Trying to understand Python objects

In article <1164206156.302 934.183510@b28g 2000cwb.googleg roups.com>,
walterbyrd <walterbyrd@ina me.comwrote:

>
>Is there some book, or other reference, that explains of this? I was
>thinking about "Python for Dummies." The "Think like a Computer
>Scientist" book, and "Dive into Python" book don't seem to explain
>Python's object model clearly enough for me.

Speaking as the co-author of _Python for Dummies_, we certainly tried to
make much of this clear, but I haven't seen any reviews yet (partly our
fault for not getting out review copies).
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"In many ways, it's a dull language, borrowing solid old concepts from
many other languages & styles: boring syntax, unsurprising semantics,
few automatic coercions, etc etc. But that's one of the things I like
about it." --Tim Peters on Python, 16 Sep 1993