Prérequis à ce tuto bien chargé :
- 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 :
DescriptionDeLObject.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.
Merci pour ce bon tuto qui va me permettre de mieux appréhender l’objet en python !!!
Très bon article avec des explications simples et claires, bravo !
Vivement la suite
Encore un article excellent ! A quand la suite? :)
TL;DR
(Merci pour ce doc, j’ai pas encore commencé le Python, ça va permettre de m’y mettre)
Ah, l’objet… j’ai beaucoup de mal avec.. pas tellement avec la notion, mais plutôt avec “qu’est-ce que je vais bien pouvoir faire de ça ?” (Faut préciser que je viens à la base des systèmes dit “mini”, qui ne connaissant pas trop l’objet..)
Je mets beaucoup d’espoir, donc, dans la suite de tes articles :)
D’après la page wikipedia, y’a qu’un ‘n’ à cuniculture.
Le site du zéro n’a qu’a bien se tenir, la concurrence arrive ! ;)
Merci :-)
@Lujeni: “when it’s ready” ™
@Léo: commence par le site du zéro. Ils sont des tutos pour la base de la base et ils sont excellents.
@Armageddon: tout à fait. C’est le plus dur quand on change de paradigme: réussir à penser en l’utilisant.
@Kontre: ;-)
Bien, trés bien, trés trés bien.
Mhéééééh, si tout avait été fait dans le même esprit que les exemples de _init_
Que cela aurait été plus facile à suivre.
Comprend-tu ?
Le nec plus ultra, serait: Sans rien enlever de l’existant, ajouter du “concret” (dans l’esprit des exemples de _init_)
Avec une ligne supplémentaire; aux lignes comme:
def methode_avec_objet_en_cours(objet_en_cours)#Prise au hasard
en mettant en commentaire ce cette ligne supplémentaire:
La mention: #concrètement
J’ai pas pigé roro. Tu veux bien me la refaire ?
Met moi un petit passage complet avec des flèches pour pointer les trucs et les machins. Ou des exemples avant / après. Je vais essayer d’améliorer tout ça.
J’ai remarqué que __init__ n’est pas tout à fait une fonction comme les autres dans la mesure où elle ne peut rien retourner.
En fait c’est plus subtile que ça, elle ne peut retourner que None.
Mais ça ne fait pas d’elle une méthode spéciale, c’est jusque que Python vérifie la valeur de retour pour éviter qu’elle retourne quelque chose.
Ca ne change rien à la nature de __init__, seul son contexte d’éxécution est différent.
Thanks maestro
Le mot: “objet” de la ligne:
def methode_avec_objet_en_cours(objet_en_cours)
Est une abstraction, dans le sens où il peut être plusieurs choses.
Les: “100”, et: “noire”, de la ligne:
def __init__(self, combien_de_carburant=100, quelle_couleur=”noire”):
Sont des “concrets”. (noir c’est noir, et rien d’autre)
Je pense que faire suivre une ligne contenant de l’abstrait, qui est l’équivalent d’une formule.
De la même ligne, dans laquelle les termes sont remplacés par des valeurs, ou des concrets (voiture, cheval…)
Qui devient alors une équation.
Serait une bonne chose.
Une sorte d’application immédiate
Et bien sûr, le top du top, serait:
Que l’ensemble du tuto soit un prog fonctionnel (fonctionnant)
Restant conscient que pour faire fonctionner un prog, il lui faut une interface; la partie: construction de l’interface serait dans une partie séparée, faisant ou non, l’objet d’un autre tuto.
On retombe ici sur des idées deja évoquées.
Bon, aprés, promis; j’arrête de mettre du poivre dans la téquilla.
Pigé. Je vais rajouter cet exemple. Par contre, je donnerai plus de concret dans la partie suivante car cette partie est déjà très longue. Je pense qu’il me faudra bien 5, 6 parties pour faire le tour.
Smouak !… Sans bave…
Bon, j’ai essayé mais j’ai pas réussi à le glisser dans cette partie. Donc je ferai des rappels dans la prochaine partie. Sorry man, la muse des artistes, tout ça.
Super article !
Il me semble qu’il y a une petite typo dans le tout premier bout de code :
>>>objet = DescriptionDeLObject()
>>>print object_tout_neuf
__main__.DescriptionDeLObject instance at 0x3112440>WtfError : object_tout_neuf is not défini
bisous
Lol, ouai clairement.
Le problème étant de conserver en parallèle la cohérence du tuto, et celle de son application, la chose doit être pensée en amont.
Et n’est pas chose facile, on en conviendra.
Bonjour,
juste une petite erreur de nommage dans la partie méthodes :
Puis plus loin dans le bout de cadre :
Excellente première partie sinon, j’ai compris plein de choses qui me semblaient compliquées. J’attend la suite avec impatience :]
Ça, c’est le genre de truc que j’adore lire en buvant un chocolat chaud…
…double effet kiss cool, le bonheur quoi !
Merci Sam & Max… ;-)
@Sam
Combien de commentaires il te faut pour écrire la partie 2? J’ai une grande famille, on peu toujours s’arranger.
@JEEK : \o/
@Etienne : y a pas de comment qui tienne. Ca sera prêt quand ça sera prêt. Demain. Dans un mois. Nous vous tenons, mouahahhaha !
Bon article, si je l’avais eu quand je n’arrivais pas à comprendre ce qu’était un objet, ou à quoi diantre cela pouvait bien servir ! Pas toujours facile quand on n’est pas programmeur professionnel !
Bref, j’ai vu un petit problème de conjugaison :
Ensuite, on créer l’objet:
C’est plutôt “on crée”
Vivement la suite !
Fixed.
Le “zéro”…Grandeur et faiblesses.
Par exemple ils font un tuto dans lequel il appellent Tkinter.
(tkinter pour les modernes)
Et bé, ils ne mettent pas d’arguments ( dimension, couleur…)
Et bé, c’est pas bien..na.
C’est dur de faire un bon tuto mine de rien:
– si tu fais trop simple, tu es loin de la réalité du terrain, et tu emmerdes très vite le lectorat
– si tu fais réaliste, tu perds la moitiers des lecteurs
Le dosage est subtil.
Bon tuto merci ! Je lirai la suite avec plaisir.
Et continuez avec des exemples concrets comme la 2ème partie avec la voiture. Parce que dans la 1ère partie, avec des noms comme objet_ceci ou objet_cela() c’est pas facile à suivre. En une phrase on prononce 10 fois le mot ‘objet’ dans notre tête et on s’y perd.
Enfin trouvé le temps de le lire.
Pas mal quand on débute (enfin avec des bases quand même) ça va me permettre de corriger quelques mauvaise pratique ;-)
Il reste quelques erreurs de typo et de nommage sur la partie déjà signalé par cym13
ze_object.methode_avec_objet_en_cours
f()methode_sans_self -> methode_sans_objet_en_cours
Puis le ‘(‘ en argument c’est exprès? (si oui c’est un peux déroutant)
methode_sans_objet_en_cours(()
Ce sont toutes des erreurs de ma part. Merci, c’est corrigé.
Merci pour ce mini-cours :)
Le lien à http://sametmax.com/cours-et-tutos/les-articles-pour-apprendre-python-dans-le-bon-ordre/ dirige vers #comments plutôt qu’au début de l’article.
Fixed. Merci.
Coucou !
Je suis d’humeur correcteuse, et ça c’est un article qui me semble intéressant, voici donc un peu de bazar :
L’objet est un moyen de dire à la machine, ce possède telle donnée, et fait telle chose avec.
L’objet est un moyen de dire à la machine : “ce possède telle donnée, et fait telle chose avec”.
un objet issue de la classe
un objet issu de la classe
Methode est juste un nom
Méthode est juste un nom
pour appeler la méthode une méthode, il nous faut forcément une instance :
pour appeler une méthode, il nous faut forcément une instance :
La plupart de choses sont des conventions.
La plupart des choses sont des conventions.
La convention la plus surprenant est celle
La convention la plus surprenante est celle
On souhaite généralement donner une état
On souhaite généralement donner un état
Il serait contre productif
Il serait contre-productif
Si vous appelez 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 :
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 :
Ça veut dire la même chose, mais ça évite l’ambiguïté du verbe “appeler”. “appeler une fonction” = “nommer une fonction” ou “exécuter une fonction”. (C’est seulement maintenant que je me rend compte de cette ambiguïté, la langue française est bizarre).
car la syntaxe self. les différencies.
car la syntaxe self. les différencie.
L’objet, c’est ce qu’on créé avec le plan.
L’objet, c’est ce qu’on crée avec le plan.
À bientôt pour le deuxième article !
Merci pour ce guide.
Quelques typos:
paramètres avancées/avancés
connaitre/connaître
(je passe sur les espaces fines insécables avant les : ; ? qui sont ou non présentes)
etc/etc. (moultes fois)
; à la fin des items de la 1e énum (sauf etc : etc.) (idem pour les autres)
“Cet objet s’appelle DescriptionDeLObject.” : pas entre balises code
. idem, plus les espaces pas insécables rendent le truc tout moche sur mon écran
“quel est ce objet_en_cours” : cet
avec des majuscules : avec des capitales
un certains nombre : certain
(liée au nom), : pas de virgule
Hé bien : Et bien
(dans le code) donc on à accès : on a
Et une méthode a accès à l’objet en cours, elle peut modifier l’objet en cours. : elle peut le modifier (sinon, ça fait lourd)
contre productif : contre-productif
automatiquement repassées à __init__(self, valeurs, passées). : argument pas dans balises code
Bon ok, je sens aue je vais avoir le droit à un “span class = tusors” mais peut etre qu’on peut preciser deux exceptions:
* le decorateur @static_method
* __new__(cls) qui prend cls et pas self
ok __new__ c’est pas utilisé avant un bon niveau en python, mais ca evite d’etre surpris
Y a 8 parties dans le guide.
Salut,
J’aimerais savoir qu’as tu fais comme études et ton parcours professionnel ?
Je suis en DUT Réseau et Télécoms et j’aimerais aller en école d’ingénieur, pour avoir un niveau comme le tiens t’as du apprendre en autodidacte ?
Cordialement.
J’ai fais un DUT en apprentissage :) L’école ne m’a pas apporté grand chose, donc oui plutôt autodidacte
D’accord :o
Merci de m’avoir répondu :)
Bonjour,
Plutôt que de dire
“Python fait comme si on avait fait :
ze_object.une_methode(ze_object)”
ne pourrait-on pas dire
“Python fait :
DescriptionDeLObject.une_methode(ze_object)” ?
Cette syntaxe a l’avantage de fonctionner.
Bien vu.