Discussion :

[Guiprogr]

Bonjour à tous,

Je me lance dans un petit RPG console et je me posais une question:

- Est-ce une utilisation correcte d'initialiser un attribut avec une de ses méthodes ?

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#!/usr/bin/python3.4
#-*- coding:utf-8 -*-
 
from random import *
 
 
class Personnage:
    def __init__(self):
        self.hp = self.init_stats()
        self.att = self.init_stats()
 
    def init_stats(self):
        return randint(2,6)
 
 
joueur = Personnage()
 
print("point de vie = %i" %joueur.hp)
print("point d'attaque = %i" %joueur.att)

Le code fonctionne mais il y a t'il possibilité de bug sur un gros projet ?

Est ce une pratique à éviter ou c'est faisable sans problème ?

[wiztricks]

Salut,

- Est-ce une utilisation correcte d'initialiser un attribut avec une de ses méthodes ?

Vous assignez vos attributs dans __init__, ce qui est raisonnable.

Le code fonctionne mais il y a t'il possibilité de bug sur un gros projet ?

Est ce une pratique à éviter ou c'est faisable sans problème ?

La méthode "init_stats" n'étant appelée que depuis __init__ est plutôt "privée".
Les attributs et méthodes "publiques" d'une classe peuvent à priori être utilisées par l'utilisateur de la classe.
Ce qui suppose documentation, tests unitaires,... et expliquer pourquoi s'en passer dans ce cas là.
En Python, public/privé ne se réalise que par des conventions de nommage: il serait préférable de préfixer cette méthode par un '_'.

Une solution que je préfère, dans ce cas, sont les "nested functions":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class Personnage:
 
    def __init__(self):
        def init_stats():
            return randint(2,6)
 
        self.hp = init_stats()
        self.att = init_stats()

- W

[VinsS]

Salut,

J'ajouterai deux commentaires gratuits.

Le shebang #!/usr/bin/python3.4 ne doit pas contenir le numéro minor (le 4, ici) ton code fonctionne avec toute version 3 et /usr/bin/ contient un lien python3 qui renvoie à la version 3 par défaut.
Tu pourras partager ton code avec des gens qui utilisent la 3.3 ou la 3.5.

L'encodage #-*- coding:utf-8 -*- n'est plus nécessaire sous Python 3. UTF-8 est l'encodage par défaut.

[wiztricks]

Salut,

Le shebang #!/usr/bin/python3.4 ne doit pas contenir le numéro minor (le 4, ici) ton code fonctionne avec toute version 3 et /usr/bin/ contient un lien python3 qui renvoie à la version 3 par défaut.
Tu pourras partager ton code avec des gens qui utilisent la 3.3 ou la 3.5.

It depends.
Si le code en question utilise des fonctionnalités 3.4 qui n'existaient pas en 3.3 ou que l'application n'a pas encore été testée sous 3.5, difficile de dire çà fonctionne avec n'importe quelle version de Python 3.

Il est préférable d’écrire (comme pour tout langage de script pouvant utiliser un "shebang") :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#!/usr/bin/env python3

et de positionner la variable d'environnement python3 en fonction du Python existant localement "qui va bien". en mentionnant dans un release notes les versions de Python testées, supportées.
note: et si vos utilisateurs ne sont pas supposés lire un release note, vous allez packager l'application via un cx_freeze pour ne pas dépendre de ce qui est installé ou pas sur l’environnement système. Il n'y a pas de "on doit", il y a des contextes et des risques qu'on peut essayer de ne pas prendre avec des contre-mesures adaptées.

L'encodage #-*- coding:utf-8 -*- n'est plus nécessaire sous Python 3. UTF-8 est l'encodage par défaut.

Là aussi "it depends". Vous avez des IDE qui utilisent cette information pour lire/sauvegarder les scripts...i.e. Python n'est pas le seul "utilisateur" de cette information.



- W