Non, juste en 1h. Mais bon, comme je te l'ai dit, j'avais déjà l'exemple en C donc je n'ai eu qu'à reprendre les fonctions C et les porter en tant que méthodes sour Python (ce que je disais quand je parlais du "presque objet" du C).
Ca sert à "privatiser" un attribut. Si tu écris self.xxx=valeurA alors de l'extérieur n'importe qui a le droit d'aller voir "xxx" et éventuellement le modifier (ex var.xxx=456 (sous-entendu que "var" est une instance de la classe en question). Et généralement le propriétaire de la classe n'aime pas qu'on touche à ses trucs. Si tu mets un double underscore, alors la variable "__xxx" n'est pas visible du dehors (bon en réalité elle est quand-même visible mais sous un autre nom assez compliqué).
Ici pour ce petit truc si les attributs avaient été utiles d'être vus depuis l'extérieur je serais passé là dessus mais comme finalement l'extérieur n'en a pas besoin, autant les cacher.
Ca dépend comment tu appelles le script. Si le script se nomme "toto.py" et que tu l'appelles de cette façon python toto.py alors oui il est inutile. Mais si tu l'appelles de cette façon ./toto.py alors c'est pour que l'OS sache qu'il faut utiliser Python. Et je spécifie "python3" au cas où tu aurais les 2 pythons sur ta machine.
T'as la même chose en shell (langage de script Unix). Tu es obligé de faire commencer tes scripts par #!/bin/sh ou #!/bin/bash ou #!/bin/csh ou #!/bin/ksh selon que tu écris en Bourne Shell, Bourne Again Shell, C-Shell, Korn Shell. Comme ça l'OS sait quel interpréteur utiliser si tu appelles le script de façon directe (sans préciser l'interpréteur).
C'est expliqué ici (partie III-D. Qui exécute ?).
Oui vas-y, c'était juste un exemple de cours socket en C donc déjà offert au public.
Comme je te l'ai expliqué: le fils ne s'occupe que du client et le père ne s'occupe que d'écouter le réseau. Chacun son job. Ensuite le client écrit et le serveur (enfin la partie "fils" du serveur) lit.
Il faut aller lire les tutoriels Python concernant les objets. Si tu as fait du C++, alors "self" Python équivaut au "this" C++. Ca permet à l'objet de pouvoir identifier en interne l'instance qui l'a invoqué. "self" veut dire "soi" en français (raccourci de "soi-même"). Donc identifie le "qui m'a invoqué" dans l'objet.
Si par exemple tu crées 2 variables a=cSocket(); b=cSocket() alors tu as 2 instances de l'objet "cSocket" dans ton programme. Si maintenant tu appelles a.listen() alors dans la fonction "listen" comment identifier que c'est "a" qui l'a appelée ? Grâce à "self" qui récupère la variable "a". L'écriture a.listen() est en fait un raccourci équivalent de l'écriture cSocket.listen(a). Donc la variable "a" passée à "listen" est récupérée dans "self" (qui aurait pu aussi s'appeler "zorglub" puisque c'est un nom de paramètre mais "self" est une convention).
"__fils" est une méthode elle aussi cachée de l'extérieur (le double underscore). Quand le client se connecte, l'objet doit effectuer un travail. Comme ce travail est assez lourd, je l'ai encapsulé dans une méthode (une fonction) de l'objet ce qui évite de tout mettre dans le "listen" (j'aurais pu mais ça aurait alourdi la lisibilité). Comme cette méthode ne sert qu'en interne, je la cache de l'extérieur. Et quand j'en ai besoin, je l'appelle depuis l'objet lui-même grâce à "self". De même qu'un objet a parfaitement le droit d'utiliser ses attributs quand il en a besoin, il a aussi parfaitement le droit d'utiliser ses propres méthodes s'il a besoin.
As-tu remarqué que dans mon exemple, quand le client se ferme, il envoie un message spécial (la chaine "EOT") au serveur pour que le serveur (enfin la partie "fils" qui gère le client) puisse savoir que le client s'arrête ? Il te faut implémenter un truc similaire (ce que Wiztricks nomme "protocole") chez-toi. il faut absolument que ton serveur sache que le client s'arrête. Tout comme tu dis "au revoir" quand tu raccroches au tel.
Si Wiztricks était là, il dirait que ton truc est "tombé en marche" et généralement dans le monde de l'informatique professionnelle on n'aime pas trop ça. Parce qu'on n'est pas sûr qu'ils "tomberont" à chaque coup. Imagine que tu montes dans un avion à destination de Londres (ville bien brumeuse) et que tu entendes l'informaticien dire "oui je comprends pas trop l'ILS (système d'atterrissage aux instruments quand le pilote ne voit rien) ne fonctionnait pas mais là ça marche mais j'ai pas trop compris pourquoi" tu serais pas fou de joie...:wow:
Désolé mais c'est comme en maths: on ne veut pas qu'un résultat, on veut un résultat démontré. Il me semble qu'il s'agit d'un TP donc si ton prof voit que ça marche "par hasard" il ne validera pas.
Ca demande l'arrêt d'un processus, pas d'un script. Généralement quand le processus est lié au script alors oui ça arrête le script. Mais si le script génère plusieurs procesus (via os.fork()) alors chaque processus devra invoquer exit() s'il veut s'arrêter (et comme exit() est interne Python, pas besoin d'utiliser celle du module "sys")
Non. Comme je l'ai dit, le fils récupère une copie de toutes les variables créées avant sa génération. Mais comme le fils possède son espace personnel et totalement isolé, il peut jouer avec ses variables sans souci de collision avec celles du père. Les processus sont tellement isolés que la majorité des soucis des dev viennent du besoin de transférer des infos les uns aux autres.
Ceci dit, rien ne vaut un bon exemple qui démontre cela
Donc le fils commence par travailler (car le père dort). Il affiche ses infos et modifie "glob". Puis il termine sur la dernière ligne du script (qui fait partie aussi du fils !!!) et affiche le "glob" modifié.Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 #!/usr/bin/env python3 # coding: utf-8 import os import time glob=123 pid=os.fork() if pid == 0: print("Je suis le fils %d (glob=%d)" % (os.getpid(), glob)) glob*=2 else: time.sleep(1) print("Je suis le père %d et mon fils est %d (glob=%d)" % (os.getpid(), pid, glob)) # if print("Ici %d bosse toujours: Etat des variables: pid=%d, glob=%d" % (os.getpid(), pid, glob))
Puis le père se réveille et fait la même chose. On voit bien que sa variable à lui n'est pas impactée par les modifs de celle du fils...
La réponse reste la même et en survolant le lien, il me semble que c'est ce qu'ils disent.