Why in class statements in Python should we extend Object?

Asked

Viewed 3,077 times

14

In the Python, when we declare a class, we extend object.

class StackExchange(object):
    def __init__(self):
        pass

I do not know if I am mistaken, but I had the impression that in some versions this is mandatory; and in others, no.

What we must go through object as a parameter? This is part of some convention?

2 answers

12


First, you are not passing any parameter, the syntax seems to refer to this but it is just Python’s way of indicating which class you are inheriting.

At one point (Python 2.2 and 2.3) there was a change in the model that the language implements the hierarchies called "new style ". In this way Python has adopted a model already adopted by some other languages, in which all objects must inherit from a single root that guarantees the existence of certain members in all objects. These members exist in the class object, so this class must always be inherited directly or indirectly - when it inherits from another class that is already inheriting the object.

Thus unifies the typing, which is a great facilitator treating the types built-in uniformly.

Some languages even do this automatically, but in addition to requiring compatibility like old style or classic, the pitonic way of coding is to be explicit (I find this inconsistent with dynamic typing, but whatever), then just looking at this point is consistent having to declare inheritance in all cases.

Of course it is still possible to use the old style, but several newer features will not work because they expect to count with these members in the classes.

In Python 3.x only the new style should be used. In general, there are no more problems of non-declaration in the object, since it has become implicit (weird, right?). However, it is recommended to do so not only to improve readability, but to facilitate a downgrade of the code used.

The change brought the super(), the descriptors and __slots__. In addition there was a change in the form of method-solving.

12

Not required, but recommended, and the behavior is different in Python 2 and 3.

According to that documentation, up to version 2.1 the class concept (class) was different from the concept of type (type), so that x.__class__ returned the class of x but type(x) always returned <type 'instance'>. From 2.2 these concepts were unified, so that a class "new-style" is simply a user-defined type, and both x.__class__ and type(x) return the same thing* - the class of x. The reason cited was:

The biggest motivation to introduce classes new-style is to promote the unification of an object model with a complete meta-model. It also has some practical benefits, such as the ability to create subclasses of most types built-in, or the introduction of "Descriptors", that allow computed properties.

For compatibility, the classes "old-style" continued to be supported in Python 2, and the default when using:

class Foo:

is the creation of a class old-style, while when using:

class Foo(object):

creates a class new-style who explicitly inherits from object. There is little reason to create classes old-style (and some benefits in using the other), so the recommended is always to use the second syntax.

In Python 3, there are no more classes old-style, all classes are new-style by default. So whether you use one or the other syntax, the result will be the same. But for the sake of consistency, so to speak, it is recommended that we still use the second syntax - which makes it more explicit which other class(s) this new class(s) is inheriting.

Some practical differences between classes old-style and new-style:

  • The new ones allow the use of super, to access members of the superclasses directly;
  • The new ones allow the use of __slots__, when you do not want an "open" class - that accepts new fields or that fields are deleted - but one with well defined and fixed fields;
  • New ones cannot be launched unless they inherit from Exception;
  • The method resolution order is different when there is multiple inheritance involved (i.e. which superclass is visited first, when the method does not exist in the class itself).

Source


* Unless it is clear that the class/object redefines __class__, but that’s another story...

Browser other questions tagged

You are not signed in. Login or sign up in order to post.