• Récupérer et afficher une ou plusieurs entrées en base de données.
• Afficher et valider un formulaire.
• Faire un mix des deux pour modifier des entrées en base.

Je ne les ai jamais aimées. Avant, les vues génériques étaient sous forme de fonction, simples, pratiques, c’était parfait. Et ça a été retiré du framework pour des versions OO sous prétexte que c’était plus flexible.

Maintenant, ce sont ces gros tas immondes, avec un ordre d’appel de méthodes complexes, des mixins dans tous les sens et une chaine d’héritage velue.

Je pense que c’est une bonne occasion pour rappeler que la POO n’est pas faite pour être utilisée partout, tout le temps. Aucun putain de paradigme de programmation n’est fait pour être utilisé partout, tout le temps. C’est pour ça qu’il y en a plusieurs.

Dans notre cas des CBV, la conséquence est que c’est un enfer pour expliquer tout usage qui ne soit pas un hello world, ce que la doc se garde bien de faire.

Après il y a toujours un malin pour dire “mais si tu vois tu fais ça, et ça, ça prend 5 lignes, c’est pas si dur”. Ouai, maintenant va expliquer ça à un stagiaire, et donne lui un exercice avec une form view qui doit modifier un objet, le lier à un user seulement si il a la permission de le faire. Juste pour voir en combien de temps il trouve. Je vais en WE à Barcelone en attendant. Je prévoie une extension à Rome pour quand il devra relire son code le trimestre prochain.

Et si encore c’était pour un gain de productivité évident, je fermerais les yeux. Mais c’est pas le cas. Même moi qui sait utiliser ces… ces choses… je dois regarder dans la doc à chaque fois que j’en utilise une. Et ensuite quand je relis mon code quelques mois plus tard, je chope de pattes d’oies aux coins des yeux.

If you have to refer to the documentation every time you use a module, find (or build) a new module.

Dixit Kenneth Reitz, le mec qui a pondu requests. Donc on va user something else que les CBV, si vous le voulez bien.

Un lecteur m’a (encore) pointé du doigt qu’un schéma du MRO et de l’ordre d’appel des méthodes serait utile. Vous vous rendez compte du truc ? On peut comprendre l’ORM sans schéma alors que c’est une machine de guerre, et il faut une carte pour comprendre comment faire un listing un peu custo avec une CBV ? J’ai évalué la somme de travail pour faire ledit schéma, et elle est énorme : trop de classes, trop de méthodes, trop de subtilités.

Bref, je jette le tablier, fuck les CBV. Je ne les inclurai plus dans mes formations, mes tutos, mes aides sur les forums, etc.

Voilà une implémentation très basique d’un objet proxy en Python :

class Proxy(object):
 
    def __init__(self, obj):
        # L'objet passé en paramètre est
        # sauvegardé dans un attribut.
        # On le fait en utilisant 
        # object.__setattr__, qui est le
        # __setattr__ du parent, et non directement
        # en faisant self._obj = obj
        # afin d'éviter une boucle infinie car
        # nous écrasons __setattr__ plus bas.
        object.__setattr__(self, "_obj", obj)
 
    # On écrase les méthodes magiques __getattribute__
    # (qui est appelée quand on faire self.nom_attribut), 
    # __delattr__ (qui est appelée quand on fait 
    # del self.nom_attribut) et __setattr__ (qui est 
    # appelée quand on fait self.nom_attribut = truc)
    def __getattribute__(self, name):
        return getattr(object.__getattribute__(self, "_obj"), name)
    def __delattr__(self, name):
        delattr(object.__getattribute__(self, "_obj"), name)
    def __setattr__(self, name, value):
        setattr(object.__getattribute__(self, "_obj"), name, value)

Ca s’utilise comme ceci :

class UnObjetOrdinnaire(object):
 
    attribut = 'VALEUR !'
 
    def methode(self, param):
        return param * 2
 
 
objet_ordinnaire = UnObjetOrdinnaire()
# on passe l'objet ordinnaire au proxy
objet_proxy = Proxy(objet_ordinnaire)
 
# Accéder à des méthodes et attribut
# du proxy accède à ceux de l'objet
# derrière le proxy
print(objet_proxy.attribut)
## VALEUR !
 
print(objet_proxy.methode(3))
## 6
 
# Modifier l'objet proxy modifie
# l'objet derrière le proxy
objet_proxy.attribut = 'une autre valeur'
 
print(objet_ordinnaire.attribut)
## une autre valeur

Pour un exemple vraiment à l’épreuve des balles, il faut prendre en compte tout un tas de cas particuliers, ce qui fait qu’il est bien plus rentable d’utiliser une lib solide pour ça.

Attention, un objet proxy peut très bien avoir des méthodes qui n’appellent pas celles de l’objet derrière. On même avoir des méthodes qui appellent des méthodes qui n’ont pas le même nom, ou plusieurs méthodes… Ce que vous voyez en exemple est un proxy très basique.

Pourquoi voudrait-on obtenir ce résultat ?

Plusieurs design patterns font appel à des objets proxy. Par exemple, le design pattern “adapter” consiste à créer un objet proxy qui accepte plusieurs types d’objets en paramètres afin de présenter toujours la même interface.

Imaginez que vous ayez plusieurs objets qui servent à s’authentifier :

 
class Login(object):
 
    _is_logged = False 
 
    def is_logged(self):
        return self._is_logged
 
    def login(self, email, password):
        self._is_logged = True
 
 
class LoginWithUsername(object):
 
    _is_logged = False 
 
    def is_logged(self):
        return self._is_logged
 
    def login(self, username, password):
        self._is_logged = True
 
 
class SignIn(object):
 
    _is_logged = False 
 
    def is_logged(self):
        return self._is_logged
 
    def signin(self, email, password):
        self._is_logged = True
 
 
class LoginWithKey(object):
 
    _is_logged = False 
 
    key = "jfjkdlmqfjdmqsjdk"
 
    def is_logged(self):
        return self._is_logged
 
    def login(self, username):
        self._is_logged = True

Et vous avez un algo de parsing, qui attend un objet d’authentification. Si vous mettez le code qui permet de choisir la bonne API dans l’algo de parsing, vous liez l’algo (qui n’a rien à voir avec l’authentification) à toutes ces implémentations.

Une des manières de faire, est d’utiliser un adaptateur, dont voici une esquisse :

class AuthAdapter(object):
 
 
    def __init__(self, obj):
        object.__setattr__(self, "_obj", obj)
 
    def __getattribute__(self, name):
 
        try:
            # Si l'attribut existe sur le proxy, on l'utilise
            return object.__getattribute__(self, name)
        except AttributeError:
            # Sinon on tente le coup sur l'objet derrière le proxy
            return getattr(object.__getattribute__(self, "_obj"), name)
 
 
    def login(self, id_=None, secret=None):
        # Le login est différent pour chaque classe,
        # donc on s'arrange avec.
        try:
            self._obj.login(id_, secret)
        except AttributeError:
            self._obj.signin(id_, secret)
        except TypeError:
            self._obj.login(id_)

En gros, si on essaye d’appeler login(), il va lisser les contours et nous donner toujours la même interface, même si derrière l’objet peut marcher complètement différement. En revanche, si on appelle n’importe quel autre attribut ou méthode (par exemple is_logged, mais il pourrait y en avoir des dizaines d’autres dans la vrai vie vivante), ça tape directement dans l’objet derrière le proxy.

Donc si j’applique l’adaptateur systématiquement, quelle que soit la classe derrière, le comportement est toujours le même : j’appelle login(un id, un secret), et il se logge.

all_auth = (Login, LoginWithUsername, SignIn, LoginWithKey)
 
for auth in all_auth:
    # 'auth' est une des 4 classes de login. On l'instancie et
    # on met l'instance derrière le proxy
    auth = AuthAdapter(auth())
    print("Testing '%s'" % auth.__class__.__name__)
    print("Is logged : %s" % auth.is_logged())
    # Le login se passe toujours de la même manière, quelle que soit la classe
    auth.login('id', 'secret')
    print("Is logged after logging : %s" % auth.is_logged())

Comme d’habitude, ceci est un exemple naval. Il est bateau quoi. Mais cela vous démontre le principe.

Le design pattern façade ressemble à l’adapter, en fait c’est une spécialisation de l’adapter. Il s’agit juste d’exposer une interface plus simple, de l’objet derrière le proxy.

Un proxy peut aussi servir à hacker une lib. Par exemple, la lib attend un objet d’une ancienne version d’une autre lib dont l’auteur a déprécié un attribut. Avec un proxy, vous pouvez toujours faire semblant que l’attribut est toujours là : enrobez l’objet dans un proxy qui possède cet attribut, tout le reste de l’API sera la même.

Un proxy peut également être utile si vous voulez effectuer des actions quand l’objet est manipulé.

import logging
 
class ProxyLogger(object):
 
    def __init__(self, obj):
        object.__setattr__(self, "_obj", obj)
 
    def __getattribute__(self, name):
        obj = object.__getattribute__(self, "_obj")
        # On lance un warning à chaque accès à un attribut de l'objet
        # derrière le proxy
        logging.warning("%s.%s has been called" % (obj.__class__.__name__, name))
        return getattr(obj, name)

Maintenant, supposons que vous avez un objet d’une lib externe (que vous ne pouvez donc pas modifier) sur lequel vous avez besoin d’infos :

class ObjetExterne(object):
    def ahahah(self):
        pass
 
o = ProxyLogger(ObjetExterne())
o.ahahah()
## WARNING:root:ObjetExterne.ahahah has been called

Vous pouvez refiler le proxy à n’importe quel objet de sa lib d’origine, si le proxy est bien fait, elle ne vera pas la différence.

On finit sur une note culture, puisque le pattern decorator utilise souvent aussi un proxy. Cette fois d’une fonction sur un autre objet (en générale une autre fonction). Mais le principe est le même. Donc quand vous voyez @un_decorateur, il est peut être en train d’appliquer un proxy à la fonction.

D’ailleurs on dit souvent que le proxy décore l’objet qui est derrière.

• comprendre parfaitement les mots clés les plus courants (conditions, tests, pass, etc);
• comprendre parfaitement les fonctions (et donc les paramètres avancées en Python);
• comprendre la notion de référence;
• connaitre les structures de données de base (string, int, list, dict, etc).

Intro

Il y a des tas de manières de programmer. Des styles. Des formes que l’on donne au code. On leur donne des noms: programmation procédurale, fonctionnelle, orientée flux, par contrat, etc. C’est ce qu’on appelle des paradigmes, des points de vue sur comment on doit faire le boulot.

En vérité, le point de vue n’est pas déterminant. Vous pouvez faire le même boulot en utilisant n’importe lequel. L’important c’est de coder.

Mais chaque point de vue possède des caractéristiques et des outils différents.

Ce que vous allez voir est ce qu’on appelle la programmation orientée objet, ou POO. C’est un simple point de vue, un outil, mais il est très utilisé en Python, Ruby ou Java.

Quand vous avez appris la programmation, on vous a montré comment stocker des données dans des structures de données:

• les listes
• les chaînes
• les entiers
• les dictionnaires
• etc

Et on vous a montré comment créer un comportement pour votre programme en utilisant des mots clés, puis plus tard en utilisant des fonctions pour regrouper ces mots clés.

En Python, à ce stade, vous utilisez des fonctions pour agir sur des structures de données.

La programmation orienté objet, c’est un style de programmation qui permet de regrouper au même endroit le comportement (les fonctions) et les données (les structures) qui sont faites pour aller ensemble.

C’est tout. C’est une simple question d’organisation du programme.

Qu’est-ce qu’un objet

Un objet est un… truc. Un machin. Un bidule.

Ça peut vous paraître une définition floue, mais c’est parce que c’est exactement ce que peut être un objet: n’importe quoi que vous décidiez de coder. L’objet est un moyen de dire à la machine : “ce < entrez_ici_un_nom_de_truc > possède telle donnée, et fait telle chose avec”.

En Python, absolument tout est un objet : une chaîne, un entier, un dictionnaire, une liste, une fonction… Vous avez donc manipulé des objets sans le savoir. Maintenant vous allez créer les vôtres.

Créer des objets se fait en deux étapes: décrire à quoi ressemble votre objet, et demander à l’ordinateur d’utiliser cette description pour le fabriquer.

En Python 2.x, cela donne ceci:

class DescriptionDeLObject:
    pass
>>> object_tout_neuf = DescriptionDeLObject()
>>> print object_tout_neuf
<__main__.DescriptionDeLObject instance at 0x3112440>

La description de l’objet (le plan de construction) est :

class DescriptionDeLObject:
    pass

C’est ce qu’on appelle une classe. La classe est le moyen, en Python, de décrire à quoi va ressembler un objet.

On dit ici:

“Cet objet s’appelle DescriptionDeLObject.”

C’est tout.

Ensuite, on crée l’objet:

>>> object_tout_neuf = DescriptionDeLObject()

DescriptionDeLObject() (notez les parenthèses), est la syntaxe Python pour dire “fabrique un objet à partir de ce plan”. Le nouvel objet va être retourné, et mis dans la variable object_tout_neuf.

La variable object_tout_neuf contient un objet issu de la classe DescriptionDeLObject, on dit qu’il contient une instance de DescriptionDeLObject. C’est pour cela que l’action de créer un objet à partir d’une classe est appelée instanciation.

Python ne sait pas grand chose sur cet objet si ce n’est son nom et son adresse en mémoire. Si on fait print dessus, c’est donc ce qu’il vous donne:

>>> print object_tout_neuf
<__main__.DescriptionDeLObject instance at 0x3112440>

On peut créer autant d’objets que l’on veut à partir d’une classe :

>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31c1d40>
>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31d6cf8>
>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31d6bd8>
>>> DescriptionDeLObject()
<__main__.DescriptionDeLObject instance at 0x31d6c68>

Méthodes

Les méthodes sont des fonctions déclarées à l’intérieur de la classe. Méthode est juste un nom pour dire “cette fonction est dans une classe”.

class DescriptionDeLObject:
 
    def la_methode(objet_en_cours):
 
        print 'Edgar Morin'

Nous avons créé une “fonction” nommée une_methode dans le bloc de la classe. Puisqu’elle est dans ce bloc, cette fonction est ce qu’on appelle une méthode.

Elle n’existe pas en dehors de la classe.

>>> la_methode()
Traceback (most recent call last):
  File "<ipython-input-12-c02691e8aa46>", line 1, in <module>
    la_methode()
NameError: name 'la_methode' is not defined

Mais, elle est attachée à chaque objet. On peut l’utiliser en faisant < variable_contenant_objet >.< nom_de_méthode >. Ainsi, pour appeler une méthode, il nous faut forcément une instance :

>>> objet_tout_neuf = DescriptionDeLObject()
>>> objet_tout_neuf.la_methode()
Edgar Morin

Arrivé à ce stade, vous devez vous demander “quel est ce objet_en_cours” qui est défini comme paramètre de la méthode ?

C’est une spécificité de Python : quand vous appelez une méthode depuis un objet, l’objet est automatiquement passé en premier paramètre par Python. C’est automatique, et invisible.

C’est très facile à comprendre en faisant une méthode qui retourne objet_en_cours pour voir ce qu’il y a dedans :

>>> class DescriptionDeLObject:
...         
...         def une_methode(objet_en_cours):
...         
...                 return objet_en_cours
...     
>>> ze_object = DescriptionDeLObject()
>>> print ze_object 
<__main__.DescriptionDeLObject instance at 0x3429170>
>>> print ze_object.une_methode()
<__main__.DescriptionDeLObject instance at 0x3429170>

Python fait comme si on avait fait :

ze_object.une_methode(ze_object)

objet_en_cours et ze_object contiennent la même chose : l’objet en cours. objet_en_cours est juste le nom que nous avons donné à notre premier argument, mais Python passe toujours automatiquement en premier argument l’objet en cours afin que vous puissiez modifier cet objet à l’intérieur d’une méthode.

On dit donc que objet_en_cours est l’instance courante.

Une méthode doit donc toujours déclarer au moins un paramètre pour accueillir la référence à l’objet en cours, sinon ça plante. Voyez plutôt :

class DescriptionDeLObject:
 
    def methode_sans_objet_en_cours():
 
        print "test"
 
    def methode_avec_objet_en_cours(objet_en_cours):
 
        print "test"
 
>>> ze_object = DescriptionDeLObject()
>>> ze_object.methode_avec_objet_en_cours() 
test
>>> ze_object.methode_sans_objet_en_cours()
Traceback (most recent call last):
  File "<ipython-input-19-90434b7e7bfa>", line 1, in <module>
    ze_object.methode_sans_objet_en_cours()
TypeError: methode_sans_objet_en_cours() takes no arguments (1 given)

Python dit que methode_sans_objet_en_cours est déclarée sans argument mais on lui en a passé un tout de même. Et en effet, Python lui a passé de manière invisible l’objet en cours en tant que premier argument.

En résumé, on déclare une classe avec une méthode ainsi:

class DescriptionDeLObject:
 
    def nom_de_methode(objet_en_cours):
 
        faire quelque chose ici

Et on l’utilise ainsi:

variable = DescriptionDeLObject()
variable.nom_de_methode()

Conventions

En Python, peu de choses sont forcées. La plupart des choses sont des conventions. Mais ce sont des conventions fortes, les gens y tiennent.

Parmi ces conventions, il y a les conventions de nommage, à savoir:

• on nomme les classes sans espace, avec des majuscules : NomDUneClasse
• on nomme le reste en minuscule avec des underscores : nom_de_methode, nom_d_attribut, etc

La convention la plus surprenante est celle du premier paramètre des méthodes qui contient l’objet en cours. Son nom n’est pas forcé, contrairement aux autres langages (comme this en Java par exemple), en fait c’est un paramètre tout à faire ordinaire. Néanmoins, la (très très forte) convention est de l’appeler self :

class DescriptionDeLObject:
 
    def nom_de_methode(self):
 
        faire quelque chose ici

Appelez-donc TOUJOURS le premier paramètre de chaque méthode self, et rappelez-vous qu’il contiendra toujours l’instance courante.

Enfin, les concepteurs de Python ont ajouté une convention supplémentaire : les méthodes appelées automatiquement sont appelées __nom_de_methode__ (avec deux underscores de chaque côté).

En effet, il existe un certains nombre de méthodes que vous pouvez écrire, et si vous les nommez d’une certaine façon, elle seront appelées automatiquement quand une condition spéciale (liée au nom), se présente.

Nous verrons cela avec la méthode __init__.

Attributs

Vous avez vu que les méthodes étaient juste des fonctions attachées à un objet. Hé bien les attributs sont juste des variables attachées à un objet.

En fait, techniquement, les méthodes sont aussi des attributs, mais faisons comme si ce n’était pas le cas et séparons :

• méthodes : fonctions pour objets
• attributs : variables pour objets

Comme Python est un langage dynamique, on peut ajouter n’importe quel attribut à n’importe quel objet en utilisant la syntaxe < objet >.< nom_attribut > :

>>> print ze_object.un_attribut # l'attribut n'existe pas
Traceback (most recent call last):
  File "<ipython-input-30-b52a599929f9>", line 1, in <module>
    ze_object.un_attribut
AttributeError: DescriptionDeLObject instance has no attribute 'un_attribut'
 
>>> ze_object.un_attribut = "valeur de l'attribut"
>>> print ze_object.un_attribut
valeur de l'attribut

Et c’est là que vous allez voir l’interêt de self :

class DescriptionDeLObject:
 
    def afficher(self):
 
        # self est l'objet en cours, donc on à accès à ses attributs !
        print self.un_attribut
 
    def modifier(self):
 
        # on peut modifier les attributs depuis l'intérieur
        self.un_attribut = "autre valeur"

On peut accéder aux attributs depuis l’intérieur et l’extérieur d’un objet :

>>> ze_object = DescriptionDeLObject() 
>>> ze_object.afficher() # l'attribut n'existe pas encore
Traceback (most recent call last):
  File "<ipython-input-35-c10abd45fc98>", line 1, in <module>
    ze_object.afficher() # l'attribut n'exite pas
  File "<ipython-input-33-3e1eb4d8e5f6>", line 5, in afficher
    print self.un_attribut
AttributeError: DescriptionDeLObject instance has no attribute 'un_attribut'
 
>>> ze_object.un_attribut = "maintenant il existe !"
>>> ze_object.afficher() 
maintenant il existe !
>>> ze_object.modifier() # l'attribut est modifié par la méthode
>>> ze_object.un_attribut 
'autre valeur'

Comme une méthode est juste une fonction attachée à un objet, on peut lui passer des paramètres. Et une méthode a accès à l’objet en cours, elle peut modifier l’objet en cours.

Donc, une méthode peut modifier l’objet en cours en fonction des paramètres passés :

class DescriptionDeLObject:
 
    def afficher(self):
 
        print "La valeur actuelle est %s" % self.un_attribut
 
    def modifier(self, valeur):
 
        self.un_attribut = valeur * 2
 
>>> ze_object = DescriptionDeLObject()
>>> ze_object.un_attribut = 1 # on met un entier en valeur cette fois
>>> ze_object.afficher()
La valeur actuelle est 1
>>> ze_object.modifier(2) # on passe un paramètre 
>>> ze_object.afficher()
La valeur actuelle est 4

Les méthodes servent exactement à cela : retourner les valeurs à l’intérieur de l’objet, ou à les modifier.

Initialisation d’un objet

On souhaite généralement donner un état de départ à tout nouvel objet créé. Par exemple, si vous travaillez sur un jeu vidéo de course de voitures, vous voudrez peut-être créer un objet voiture avec du carburant et une couleur de peinture.

Il serait contre productif de devoir les spécifier à chaque fois. Pour automatiser le travail, Python met à disposition des méthodes appelées automatiquement quand une condition est remplie. Ce sont les méthodes nommées __methode__.

Dans notre cas, on veut que notre objet ait un état de départ, donc on va utiliser la méthode qui est appelée automatiquement après la création de l’objet. C’est la méthode __init__.

Si vous définissez une méthode avec le nom __init__, Python va automatiquement, et de manière invisible, appeler la méthode après avoir créé l’objet :

class DescriptionDeLObject:
 
    def __init__(self):
 
        print "L'objet a été créé !"
        print "La méthode est appelée automatiquement"
 
>>> ze_object = DescriptionDeLObject()
L'objet a été créé !
La méthode est appelée automatiquement

__init__ est une méthode tout à fait ordinaire. Seul le nom est important: comme elle est appelée ainsi, Python la détecte automatiquement et l’appelle au bon moment.

C’est très utile pour fournir un état de départ:

class Voiture:
 
    def __init__(self):
 
        self.carburant = 100
        self.couleur = "noire"
 
>>> v = Voiture()
>>> v.couleur
'noire'
>>> v.carburant
100

Bien entendu, on veut généralement pouvoir changer l’état de départ. Ici encore, Python nous aide: si vous passez des paramètres à l’instanciation, ils sont passés automatiquement à __init__.

Comme __init__ est une méthode ordinaire (et donc une fonction), on peut lui donner des paramètres avec des valeurs par défaut mais accepter une nouvelle valeur si elle est passée :

class Voiture:
 
    def __init__(self, combien_de_carburant=100, quelle_couleur="noire"):
 
        self.carburant = combien_de_carburant
        self.couleur = quelle_couleur
 
 
>>> v1 = Voiture() # sans paramètres, les valeurs par défaut sont utilisées
>>> v1.couleur
'noire'
>>> v1.carburant
100
>>> v2 = Voiture(50, 'rouge et jaune à petit pois') # on change les valeurs
>>> v2.couleur 
'rouge et jaune \xc3\xa0 petit pois'
>>> v1.couleur
'noire'
>>> v3 = Voiture(quelle_couleur="fushia virant sur l'aigue marine")
>>> v3.couleur
"fushia virant sur l'aigue marine"
>>> v3.carburant
100

Les valeurs passées dans Voiture(valeurs, passées), sont automatiquement repassées à __init__(self, valeurs, passées).

En résumé : __init__ est appelée automatiquement après que l’objet soit créé, et on lui passe les paramètres passés à l’instanciation. Comme __init__ est une méthode et a accès à l’instance courante, elle peut ajouter des attributs à l’objet en cours en fonction de ces paramètres. On utilise ça pour créer des objets avec un état de départ par défaut, et permettre une personnalisation de cet état de départ.

J’ai mis des noms différents pour les paramètres d’__init__ et les attributs de l’objet, mais en réalité on leur met souvent le même nom par convention. Donc l’exemple ci-dessus s’écrirait plutôt :

class Voiture:
 
    def __init__(self, carburant=100, couleur="noire"):
 
        self.carburant = carburant
        self.couleur = couleur

carburant et couleur ne sont pas la même chose que self.carburant et self.couleur : les premiers n’existent que dans __init__. Une fois qu’__init__ a fini de s’exécuter, ils disparaissent. Les seconds sont des attributs de l’objet en cours, et sont donc toujours disponibles tant que l’objet existe. Le fait qu’ils portent le même nom ne pose aucun problème car la syntaxe self. les différencie.

Résumé final

La classe, c’est un plan.

L’objet, c’est ce qu’on crée avec le plan.

Une méthode, c’est une fonction déclarée dans une classe (qui est attachée à chaque objet produit, et on lui passe en premier paramètre l’objet en cours).

Un attribut, c’est une variable attachée à un objet.

Une instance d’une classe, c’est l’objet issu d’une classe.

Un spermophile, c’est un animal dont la queue est assez courte et plus ou moins fournie. Il aime être à 4 pattes et mange parfois des glands. Ça n’a rien à voir, mais je me suis dit qu’il fallait faire passer l’info. Ah oui, et la cuniculture, c’est prendre soin d’un lapinou. La levrette, par contre, n’est pas la femelle du lièvre.

Le vocabulaire en informatique, c’est primordial.

La partie 2, c’est par ici.