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

Discussion in 'Python' started by looping, Apr 11, 2006.

  1. looping

    looping Guest

    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 ?
    looping, Apr 11, 2006
    #1
    1. Advertising

  2. looping

    Georg Brandl Guest

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

    looping wrote:
    > 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 ?


    class C():

    is meant to be synonymous with

    class C:

    and therefore cannot create a new-style class.

    Georg
    Georg Brandl, Apr 11, 2006
    #2
    1. Advertising

  3. looping

    Peter Hansen Guest

    Georg Brandl wrote:
    > 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
    Peter Hansen, Apr 11, 2006
    #3
  4. looping

    Georg Brandl Guest

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

    Peter Hansen wrote:
    > Georg Brandl wrote:
    >> 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?


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

    Georg
    Georg Brandl, Apr 11, 2006
    #4
  5. looping

    looping Guest

    Peter Hansen wrote:
    > Georg Brandl wrote:
    > > 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


    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)
    looping, Apr 11, 2006
    #5
  6. Re: Why new Python 2.5 feature "class C()" return old-style class?

    looping wrote:
    > Peter Hansen wrote:
    >
    >>Georg Brandl wrote:
    >>
    >>>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

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


    --
    bruno desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
    bruno at modulix, Apr 11, 2006
    #6
  7. looping

    Guest

    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
    , Apr 11, 2006
    #7
  8. looping

    looping Guest

    bruno at modulix wrote:
    > looping wrote:
    > > Peter Hansen wrote:
    > >
    > >>Georg Brandl wrote:
    > >>
    > >>>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

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


    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.
    looping, Apr 11, 2006
    #8
  9. looping

    Georg Brandl Guest

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

    looping wrote:
    > Peter Hansen wrote:
    >> Georg Brandl wrote:
    >> > 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

    >
    > 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
    Georg Brandl, Apr 11, 2006
    #9
  10. 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

    --
    Felipe.
    Felipe Almeida Lessa, Apr 11, 2006
    #10
  11. looping

    Aahz Guest

    In article <>,
    <> wrote:
    >
    >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.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "LL YR VWL R BLNG T S"
    Aahz, Apr 11, 2006
    #11
  12. Re: Why new Python 2.5 feature "class C()" return old-style class?

    wrote:
    > 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 desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
    bruno at modulix, Apr 11, 2006
    #12
  13. Re: Why new Python 2.5 feature "class C()" return old-style class?

    looping wrote:
    > bruno at modulix wrote:
    >
    >>looping wrote:
    >>
    >>>Peter Hansen wrote:
    >>>
    >>>
    >>>>Georg Brandl wrote:
    >>>>
    >>>>
    >>>>>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
    >>>
    >>>
    >>>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.
    >>

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


    --
    bruno desthuilliers
    python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    p in ''.split('@')])"
    bruno at modulix, Apr 11, 2006
    #13
  14. looping

    looping Guest

    Georg Brandl wrote:
    > 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.
    looping, Apr 11, 2006
    #14
  15. looping

    Duncan Booth Guest

    bruno at modulix wrote:

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


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

    >>> from __future__ import with_statement
    >>> type(with_statement)

    <type 'instance'>

    (yes, I know that the _Feature class isn't actually new, just this
    particular instance of it.)
    Duncan Booth, Apr 11, 2006
    #15
  16. looping

    Aahz Guest

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

    In article <443bbdbe$0$15517$>,
    bruno at modulix <> wrote:
    >
    >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).
    --
    Aahz () <*> http://www.pythoncraft.com/

    "LL YR VWL R BLNG T S"
    Aahz, Apr 11, 2006
    #16
  17. looping

    Peter Otten Guest

    Aahz wrote:

    > 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
    Peter Otten, Apr 11, 2006
    #17
  18. 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?

    --
    Felipe.
    Felipe Almeida Lessa, Apr 11, 2006
    #18
  19. Re: Why new Python 2.5 feature "class C()" return old-style class?

    Aahz wrote:
    > 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
    Wildemar Wildenburger, Apr 11, 2006
    #19
  20. looping

    Robert Kern Guest

    Wildemar Wildenburger wrote:
    > Aahz wrote:
    >
    >>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?


    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


    "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
    Robert Kern, Apr 11, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dlo_olb
    Replies:
    2
    Views:
    2,278
    Fredrik Lundh
    Jun 25, 2003
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,682
    Smokey Grindel
    Dec 2, 2006
  3. G Fernandes

    is this definition old-style or new-style

    G Fernandes, Feb 27, 2005, in forum: C Programming
    Replies:
    8
    Views:
    419
    Andrey Tarasevich
    Mar 1, 2005
  4. Kza
    Replies:
    4
    Views:
    408
    Andrew Koenig
    Mar 3, 2006
  5. Jayden
    Replies:
    9
    Views:
    275
    alex23
    Sep 27, 2012
Loading...

Share This Page