Why new Python 2.5 feature "class C()" return old-style class ?

[looping]

For Python developers around.

From Python 2.5 doc:

The list of base classes in a class definition can now be empty. As an
example, this is now legal:
class C():
pass

nice but why this syntax return old-style class, same as "class C:",
and not the new style "class C(object):" ?
Old-style class are somewhat deprecated and could be almost always be
replaced by new-style class, so this syntax could be a nice shortcut to
create them.

Am I wrong or is there something that I've missed ?

 

[Georg Brandl]

For Python developers around.

The list of base classes in a class definition can now be empty. As an
example, this is now legal:
class C():
pass

nice but why this syntax return old-style class, same as "class C:",
and not the new style "class C(object):" ?
Old-style class are somewhat deprecated and could be almost always be
replaced by new-style class, so this syntax could be a nice shortcut to
create them.

Am I wrong or is there something that I've missed ?

class C():

is meant to be synonymous with

class C:

and therefore cannot create a new-style class.

Georg

 

[Peter Hansen]

class C():

is meant to be synonymous with

class C:

and therefore cannot create a new-style class.

I think "looping" understands that, but is basically asking why anyone
is bothering with a change that involves a part of the language that is
effectively deprecated. In other words, class(): never used to be
valid, so why make it valid now?

-Peter

 

[Georg Brandl]

I think "looping" understands that, but is basically asking why anyone
is bothering with a change that involves a part of the language that is
effectively deprecated. In other words, class(): never used to be
valid, so why make it valid now?

I don't recall that, you'll have to search the python-dev archives.

Georg

 

[looping]

I think "looping" understands that, but is basically asking why anyone
is bothering with a change that involves a part of the language that is
effectively deprecated. In other words, class(): never used to be
valid, so why make it valid now?

-Peter

Exact.
But I think that if we make "class C():" a synonym of "class
C(object):", it will save lot of keystrokes ;-)
So I think the idea is great but the result is not actually very
usefull.

Delphi (Pascal?) use almost the same concept:
TTest = class

is a synonym of

TTest = class(TObject)

 

[bruno at modulix]

Exact.
But I think that if we make "class C():" a synonym of "class
C(object):", it will save lot of keystrokes ;-)

Since the class statement without superclass actually creates an
old-style class, I'd expect the "class MyClass():" variant to behave
the same. Sacrifying readability and expliciteness just to save half a
dozen keystrokes is not pythonic IMHO.

 

[bearophileHUGS]

bruno at modulix>Since the class statement without superclass actually
creates an old-style class, I'd expect the "class MyClass():" variant
to behave the same.<

In Python 3.0 I really hope the

class C: pass
class C(): pass
class C(object): pass

will mean the same thing. (So in Python 2.5 the second version can be
made to mean the same thing of the third).

Bye,
bearophile

 

[looping]

Since the class statement without superclass actually creates an
old-style class, I'd expect the "class MyClass():" variant to behave
the same. Sacrifying readability and expliciteness just to save half a
dozen keystrokes is not pythonic IMHO.

I don't think readability suffer and expliciteness could sometimes be
sacrified to simplify the life of developer: ex "abcd"[0:3] ->
"abcd"[:3].
And for newbies, the somewhat magic behavior of the "object" superclass
is not so clear even that it is very explicit.
When I write script I don't use new-style class cause is bother me to
type "(object)" when I don't need their features. But in an other hand,
I believe that new-style class are faster to instanciate (maybe I'm
wrong...).
So this new syntax is a good way to boost their uses without bother
with compatibility of existing code IMHO.

Well I stop to argue now and let Python Dev make their (very good) job.

 

[Georg Brandl]

Exact.
But I think that if we make "class C():" a synonym of "class
C(object):", it will save lot of keystrokes ;-)

If you have many classes in a module, putting

__metaclass__ = type

at the top can save you these keystrokes.

Georg

 

[Felipe Almeida Lessa]

Em Ter, 2006-04-11 às 06:49 -0700, looping escreveu:

But in an other hand,
I believe that new-style class are faster to instanciate (maybe I'm
wrong...).

$ python2.4 -m timeit -s 'class x: pass' 'x()'
1000000 loops, best of 3: 0.435 usec per loop
$ python2.4 -m timeit -s 'class x(object): pass' 'x()'
1000000 loops, best of 3: 0.316 usec per loop

 

[Aahz]

In Python 3.0 I really hope the

class C: pass
class C(): pass
class C(object): pass

will mean the same thing.

The BDFL made that one of the very first Pronouncements of 3.0. ;-)

(So in Python 2.5 the second version can be made to mean the same thing
of the third).

Can, yes. But should it? The whole point of adding the () option to
classes was to ease the learning process for newbies who don't
understand why classes have a different syntax from functions. Having

class C(): pass

behave differently from

class C: pass

would be of no benefit for that purpose.

 

[bruno at modulix]

bruno at modulix>Since the class statement without superclass actually
creates an old-style class, I'd expect the "class MyClass():" variant
to behave the same.<

In Python 3.0 I really hope the

class C: pass
class C(): pass
class C(object): pass

will mean the same thing.

Yes, but this is for 3.0. Actually we're still at 2.5.

 

[bruno at modulix]

I don't think readability suffer

It does. The statement "class X():" imply there's no superclass, so it
definitiveley should behave the same as "class X:".

and expliciteness could sometimes be
sacrified to simplify the life of developer: ex "abcd"[0:3] ->
"abcd"[:3].

Here there's no ambiguity.

And for newbies, the somewhat magic behavior of the "object" superclass
is not so clear even that it is very explicit.

There's no magic involved here. And I really doubt that having
inconsistant behaviour for "class X():" wrt/ "class X:" will help here.

When I write script I don't use new-style class

You should.

cause is bother me to
type "(object)" when I don't need their features.

Please repeat this 101 times each morning:
"thou shall not use old-style classes for they are deprecated".

(snip)

So this new syntax is a good way to boost their uses without bother
with compatibility of existing code IMHO.

It's mostly a good way to add inconsistency and confusion to a situation
that's already confusing enough for newbies.

 

[looping]

If you have many classes in a module, putting

__metaclass__ = type

at the top can save you these keystrokes.

Georg

We could do that ? Nice trick that I've never thoughts about myself.

Thanks Georg.

 

[Duncan Booth]

Please repeat this 101 times each morning:
"thou shall not use old-style classes for they are deprecated".

It's a pity though that Python still uses old-style classes internally,
even for some things which are brand new:
<type 'instance'>

(yes, I know that the _Feature class isn't actually new, just this
particular instance of it.)

 

[Aahz]

Please repeat this 101 times each morning:
"thou shall not use old-style classes for they are deprecated".

Classic classes are *NOT* deprecated. And Python for Dummies will make
that clear (though we will note that there are people in the community
who believe as you do).

 

[Peter Otten]

The whole point of adding the () option to
classes was to ease the learning process for newbies who don't
understand why classes have a different syntax from functions.

That cuts both ways. Now a determined newbie won't understand why

def f: pass

and

bases = A, B
class C(*bases): pass

don't work as expected...

Peter

 

[Felipe Almeida Lessa]

Em Ter, 2006-04-11 às 07:17 -0700, Aahz escreveu:

Can, yes. But should it? The whole point of adding the () option to
classes was to ease the learning process for newbies who don't
understand why classes have a different syntax from functions. Having

class C(): pass

behave differently from

class C: pass

would be of no benefit for that purpose.

Why should a newbie use an old-style class?

 

[Wildemar Wildenburger]

Classic classes are *NOT* deprecated.

I'm surprised ...
So there will be two (in most cases subtly) different classes of classes
(so to speak) for all eternity?

Why is that? Do classic classes have some advantage over new style ones?
If so, what are they?

eagerly:
wildemar

 

[Robert Kern]

I'm surprised ...
So there will be two (in most cases subtly) different classes of classes
(so to speak) for all eternity?

No, Python 3.0, the backwards-compatibility-breaking release, will remove them.
"Deprecated" has a rather specific meaning for Python language features and
doesn't really apply to classic classes, yet.

http://www.python.org/dev/peps/pep-0005/

Why is that? Do classic classes have some advantage over new style ones?
If so, what are they?

There's a slight speed advantage in some places, but nothing you should worry
about. I, at least, would recommend always using new classes in new code unless
if you are sure you need classic classes.

--
Robert Kern
(e-mail address removed)

"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