Trying to understand Python objects

[Bruno Desthuilliers]

Re: Trying to understand Python objects

Aahz a écrit :

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.

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...

[George Sakkis]

Re: Trying to understand Python objects

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

[Fredrik Lundh]

Re: Trying to understand Python objects

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>

[Bruno Desthuilliers]

Re: Trying to understand Python objects

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...

[Carl Banks]

Re: Trying to understand Python objects


Aahz wrote:

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.

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


Carl Banks

[Aahz]

Re: Trying to understand Python objects

In article <4565f8f7$0$846 0$426a74cc@news .free.fr>,
Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.frwrote :

>Aahz a écrit :

>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.

>
>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 (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