Re: Trying to understand Python objects

2006-11-24 Thread Aahz
In article [EMAIL PROTECTED],
Bruno Desthuilliers  [EMAIL PROTECTED] wrote:
Aahz a écrit :
 In article [EMAIL PROTECTED],
 Ben Finney  [EMAIL PROTECTED] wrote:
 
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.

Don't see it as a religious point please, but I fail to understand why 
you seem so in love with old-style classes ? new-style classes are the 
official Python object model since 2.2 (which is a few years ago now), 
and the last mandatory use of them (exceptions...) disappeared with the 
2.5. AFAIK, everything you do with old-style classes can be done with 
new-style ones. FWIW, old-style classes support is now only for backward 
compat. So *why* insisting on using them ?

There's a big difference between saying always use old-style classes
and classic classes are just fine.  So I'm certainly not in love with
or insisting on using classic classes.  Mostly what I'm saying is that
I think it's kinda gross and grotesque for newcomers to be told to use

class Point(object):
pass

instead of

class Point:
pass

You are also wrong about new-style classes being the official object
model -- the tutorial doesn't even mention them yet!  I also think that
new-style classes should be avoided in Python 2.2 because of the subtle
differences that were introduced in 2.3 -- and 2.2 is still in active
use.
-- 
Aahz ([EMAIL PROTECTED])   * 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Trying to understand Python objects

2006-11-23 Thread Aahz
In article [EMAIL PROTECTED],
Ben Finney  [EMAIL PROTECTED] wrote:

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 ([EMAIL PROTECTED])   * 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Trying to understand Python objects

2006-11-23 Thread Aahz
In article [EMAIL PROTECTED],
walterbyrd [EMAIL PROTECTED] wrote:

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 ([EMAIL PROTECTED])   * 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Trying to understand Python objects

2006-11-23 Thread Bruno Desthuilliers
Aahz a écrit :
 In article [EMAIL PROTECTED],
 Ben Finney  [EMAIL PROTECTED] wrote:
 
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.

Don't see it as a religious point please, but I fail to understand why 
you seem so in love with old-style classes ? new-style classes are the 
official Python object model since 2.2 (which is a few years ago now), 
and the last mandatory use of them (exceptions...) disappeared with the 
2.5. AFAIK, everything you do with old-style classes can be done with 
new-style ones. FWIW, old-style classes support is now only for backward 
compat. So *why* insisting on using them ?

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


Re: Trying to understand Python objects

2006-11-23 Thread George Sakkis
Bruno Desthuilliers wrote:

 AFAIK, everything you do with old-style classes can be done with new-style 
 ones.

The only thing I occasionally (or rather rarely) miss about old-style
classes is instance-specific special methods:

 class C:
... def __init__(self,x):
... self.__getitem__ = lambda i: i*x
...
 c=C(2)
 c[3]
6
 class N(object):
... def __init__(self,x):
... self.__getitem__ = lambda i: i*x
...
 n=N(2)
 n[3]
Traceback (most recent call last):
  File stdin, line 1, in ?
TypeError: unindexable object

Of course this example can be rewritten to work for new style classes;
a trickier would be to bind the instance attribute conditionally;
here's a silly example:

 class C:
... def __init__(self,x):
... if random.random()  0.5:
... self.__getitem__ = lambda i: i*x

I'm not sure if this is a conscious choice or a technical limitation of
how new-style classes work internally, but I've had a use for it at
least once.

George

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


Re: Trying to understand Python objects

2006-11-23 Thread Fredrik Lundh
Bruno Desthuilliers wrote:

 Don't see it as a religious point please, but I fail to understand why 
 you seem so in love with old-style classes ? new-style classes are the 
 official Python object model since 2.2 (which is a few years ago now), 
 and the last mandatory use of them (exceptions...) disappeared with the 
 2.5. AFAIK, everything you do with old-style classes can be done with 
 new-style ones. FWIW, old-style classes support is now only for backward 
 compat. So *why* insisting on using them ?

to pick a few reasons: the old-style/new-style distinction is com-
pletely irrelevant for people new to the language, attribute access
is slower for new-style classes (!), they'll be default in 3.0 any-
way...

/F

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


Re: Trying to understand Python objects

2006-11-23 Thread Bruno Desthuilliers
Fredrik Lundh a écrit :
 Bruno Desthuilliers wrote:
 
 Don't see it as a religious point please, but I fail to understand why 
 you seem so in love with old-style classes ? 
(snip)
 
 to pick a few reasons: the old-style/new-style distinction is com-
 pletely irrelevant for people new to the language,

Until they try to use properties...

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


Re: Trying to understand Python objects

2006-11-23 Thread Carl Banks

Aahz wrote:
 In article [EMAIL PROTECTED],
 Ben Finney  [EMAIL PROTECTED] wrote:
 
 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.

Absolutely.  We don't want newbies' feeble brains to explode.


Carl Banks

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


Re: Trying to understand Python objects

2006-11-22 Thread Fredrik Lundh
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

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


Re: Trying to understand Python objects

2006-11-22 Thread Bruno Desthuilliers
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 '[EMAIL PROTECTED]'.split('@')])
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Trying to understand Python objects

2006-11-22 Thread walterbyrd
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.

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


Re: Trying to understand Python objects

2006-11-22 Thread Ben Finney
walterbyrd [EMAIL PROTECTED] writes:

 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

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


Re: Trying to understand Python objects

2006-11-21 Thread Robert Kern
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

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


Re: Trying to understand Python objects

2006-11-21 Thread Ben Finney
walterbyrd [EMAIL PROTECTED] writes:

 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 

Re: Trying to understand Python objects

2006-11-21 Thread George Sakkis
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

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


Re: Trying to understand Python objects

2006-11-21 Thread Ben Finney
Ben Finney [EMAIL PROTECTED] writes:

 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

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