Y a-t-il une raison pour qu'une déclaration de classe hérite object?
En Python 3, mis à part la compatibilité entre Python 2 et 3, aucune raison . En Python 2, plusieurs raisons .
Histoire de Python 2.x:
Dans Python 2.x (à partir de la version 2.2), il existe deux styles de classes en fonction de la présence ou de l'absence de objectclasse de base:
classes de style "classique" : elles n'ont pas objectcomme classe de base:
>>> class ClassicSpam: # no base class
... pass
>>> ClassicSpam.__bases__
()
"nouvelles" classes de style : elles ont, directement ou indirectement (par exemple hériter d'un type intégré ), objectcomme classe de base:
>>> class NewSpam(object): # directly inherit from object
... pass
>>> NewSpam.__bases__
(<type 'object'>,)
>>> class IntSpam(int): # indirectly inherit from object...
... pass
>>> IntSpam.__bases__
(<type 'int'>,)
>>> IntSpam.__bases__[0].__bases__ # ... because int inherits from object
(<type 'object'>,)
Sans aucun doute, lors de l'écriture d'une classe, vous aurez toujours envie d'opter pour des classes de nouveau style. Les avantages de le faire sont nombreux, pour en énumérer certains:
Prise en charge des descripteurs . Plus précisément, les constructions suivantes sont rendues possibles avec des descripteurs:
classmethod: Une méthode qui reçoit la classe comme argument implicite au lieu de l'instance.staticmethod: Une méthode qui ne reçoit pas l'argument implicite self comme premier argument.- propriétés avec
property: Créer des fonctions pour gérer l'obtention, la définition et la suppression d'un attribut.
__slots__: Enregistre les consommations de mémoire d'une classe et accélère également l'accès aux attributs. Bien sûr, cela impose des limitations .
La __new__méthode statique: vous permet de personnaliser la façon dont les nouvelles instances de classe sont créées.
Ordre de résolution des méthodes (MRO) : dans quel ordre les classes de base d'une classe seront recherchées lors de la tentative de résolution de la méthode à appeler.
Lié au MRO, aux superappels . Voir aussi, super()considéré comme super.
Si vous n'héritez pas object, oubliez-les. Une description plus exhaustive des puces précédentes ainsi que d'autres avantages des "nouvelles" classes de style peuvent être trouvées ici .
L'un des inconvénients des classes de nouveau style est que la classe elle-même est plus gourmande en mémoire. À moins que vous ne créiez de nombreux objets de classe, je doute que ce soit un problème et que ce soit un naufrage négatif dans une mer de points positifs.
Histoire de Python 3.x:
En Python 3, les choses sont simplifiées. Seules les classes de nouveau style existent (appelées clairement classes) donc la seule différence dans l'ajout objectest de vous obliger à taper 8 caractères supplémentaires. Cette:
class ClassicSpam:
pass
est complètement équivalent (à part leur nom :-) à ceci:
class NewSpam(object):
pass
et à cela:
class Spam():
pass
Tous ont objecten leur __bases__.
>>> [object in cls.__bases__ for cls in {Spam, NewSpam, ClassicSpam}]
[True, True, True]
Alors, que devrais-tu faire?
En Python 2: toujours hérité de objectexplicitement . Obtenez les avantages.
En Python 3: héritez de objectsi vous écrivez du code qui essaie d'être agnostique Python, c'est-à-dire qu'il doit fonctionner à la fois en Python 2 et en Python 3. Sinon, cela ne fait vraiment aucune différence puisque Python l'insère pour vous Dans les coulisses.