Discussion :

[Sve@r]

Bonjour à tous

Initié à Python depuis cet été, j'arrive maintenant dans des applications un peu complexes avec beaucoup d'objets imbriqués dans une hiérarchie forte.
Et donc quand je code les objets, l'imbrication des uns dans les autres et les tabulations associées font que je me retrouve à programmer trop à droite.

Exemple simple: un rectangle qui comporte 4 coins

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#!/usr/bin/env python
# coding: Latin-1 -*-
 
class cRectangle:
	"Rectangle"
	def __init__(self, l, L):
		self.l=l
		self.L=L
		self.coin=[]
		self.coin.append(self.cPoint(0, 0))
		self.coin.append(self.cPoint(0, L))
		self.coin.append(self.cPoint(l, L))
		self.coin.append(self.cPoint(l, 0))
 
	def aff(self):
		txt=""
		txt+="Rectangle %d/%d\n" % (self.l, self.L)
		for i,coin in enumerate(self.coin):
			txt+="coin[%d]=%s\n" % (i + 1, coin.aff())
		return txt
 
	class cPoint:
		"Point mathématique"
 
		def __init__(self, x=0, y=0):
			self.x=x;
			self.y=y;
 
		def aff(self):
			txt="x=%d, y=%d\n" % (self.x, self.y)
			return txt
 
a=cRectangle(20, 10)
print a.aff()

Donc je définis mon objet cRectangle (avec les méthodes qui vont bien et leur tabulations obligatoires). Puis mon rectangle utilisant des points, j'ai alors un sous-objet "cPoint" mais j'ai un niveau de tabulations en plus. Si mon point utilisait un sous-objet, j'aurais alors un 3° niveau de tabulations etc etc. Si j'arrive à 5 niveaux de profondeur, mon code est totalement à droite et je n'ai plus de place.

Je tiens cette habitude d'objets imbriqués du C++ mais là, je n'ai pas de problème car en C++ on peut déclarer ses objets avant de les coder et dans la syntaxe du codage, il suffit d'indiquer la hiérarchie mais le code reste à gauche de l'écran.

Si quelqu'un a déjà connu ce problème et a trouvé une solution pour le régler (solution plus élaborer que répondre "t'as qu'à réduire l'espace affiché par ta tabulation"...

[tamiel]

J'avoue que pour python j'utilise 2 espaces à la place de la tabulation classique.

Mais quelque chose m'intrigue : je ne vois pas l'intérêt de ta sous classe cPoint, elle peut être définie séparément sans problème .

[pacificator]

Mais quelque chose m'intrigue : je ne vois pas l'intérêt de ta sous classe cPoint, elle peut être définie séparément sans problème .

+1

Pourquoi ne pas utiliser la fonction __repr__, c'est pratique pour debugger?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
>>> class Point(object):
...     def __init__(self, x=0, y=0):
...         self.x = x
...         self.y = y
...     def __repr__(self):
...         return "x=%d, y=%i" % (self.x, self.y)
...
>>> p0 = Point(0, 0)
>>> p1 = Point(5, 12)
>>> print p0
x=0, y=0
>>> p1
x=5, y=12

[Sve@r]

J'avoue que pour python j'utilise 2 espaces à la place de la tabulation classique.

Ben déjà, sous les éditeurs actuels, il est courant de trouver une option pour définir le nb d'epaces associé aux tabulations et ça fait longtemps que sur le mien ("vi") je l'ai défini à 4. Tu pourrais donc utiliser la tabulation définie à 2 au lieu de tes 2 espaces mais c'est juste décaler le problème, pas le résoudre...

Mais quelque chose m'intrigue : je ne vois pas l'intérêt de ta sous classe cPoint, elle peut être définie séparément sans problème .

Là c'est juste un exemple illustratif d'un problème qui se pose parce que je commence à bosser avec 3 ou 4 classes, et chacune peut avoir 3 ou 4 sous-classes. Imagine que j'ai besoin d'avoir une classe Parent1 (avec sa sous-classe Enfant) puis une autre Parent2 (avec elle aussi une sous-classe Enfant) puis une 3° Parent3 (sous-classe Enfant)

Si je définis ma classe Parent1 puis ma classe Enfant jusque là ça va. Puis je crée Parent2 mais là, je ne peux pas définir de classe Enfant puisqu'elle existe déjà. Alors quoi. Vais-je devoir nommer ma classe Enfant2 pour ne pas créer de conflit et ainsi de suite ? Admettons mais c'est dommage d'avoir possibilité de limiter un mnémonique "Enfant" à la seule vision de la classe dans laquelle il est utilisé (ce qui me permet de ne pas avoir à me préoccuper des homonymies) et de ne pas pouvoir s'en servir parce que je n'ai plus la place de coder. Surtout si les classes "Enfant" ont elles-aussi des sous-classes.

Pourquoi ne pas utiliser la fonction __repr__, c'est pratique pour debugger?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
>>> class Point(object):
...     def __init__(self, x=0, y=0):
...         self.x = x
...         self.y = y
...     def __repr__(self):
...         return "x=%d, y=%i" % (self.x, self.y)
...
>>> p0 = Point(0, 0)
>>> p1 = Point(5, 12)
>>> print p0
x=0, y=0
>>> p1
x=5, y=12

Ouaip. Je la connaissais mais là j'ai codé très vite pour l'exemple et je n'ai pas eu le réflexe. Mais cela ne fait pas avancer le schmiliblik

[dividee]

Si je définis ma classe Parent1 puis ma classe Enfant jusque là ça va. Puis je crée Parent2 mais là, je ne peux pas définir de classe Enfant puisqu'elle existe déjà. Alors quoi. Vais-je devoir nommer ma classe Enfant2 pour ne pas créer de conflit et ainsi de suite ? Admettons mais c'est dommage d'avoir possibilité de limiter un mnémonique "Enfant" à la seule vision de la classe dans laquelle il est utilisé (ce qui me permet de ne pas avoir à me préoccuper des homonymies) et de ne pas pouvoir s'en servir parce que je n'ai plus la place de coder. Surtout si les classes "Enfant" ont elles-aussi des sous-classes.

Je dirais dans un cas comme celui-là qu'il vaudrait mieux créer plusieurs modules. Deux classes peuvent avoir le même nom si elles sont dans des modules différents.

[pacificator]

Ouaip. Je la connaissais mais là j'ai codé très vite pour l'exemple et je n'ai pas eu le réflexe. Mais cela ne fait pas avancer le schmiliblik

Je suis d'accord mais considérant qu'en python, il y a très souvent une seule manière de bien faire les choses, je préfère utiliser __repr__

Et le schmiliblik n'avance toujours pas ....

Les classes Enfant de tes différentes classes possèdent-elle des relations sémantiques entre elles?
Ne devraient-elles pas être héritées?
Pourquoi ne pas les sortir de tes définitions?

Mieux vaut le plat que l'imbriqué.

Etant inculte en C++, je ne perçois pas l'utilité pratique de ce genre de structure.

[pfeuh]

Salut,

je préfère utiliser __repr__

Il semble que __str__ fasse la même chose que __repr__, mais me paraît plus clair, vu que ces fonctions ne peuvent retourner que des chaines. J'ai l'impression - mais je peux me tromper - que __repr__ n'est qu'une encapsulation de __str__, car quand on essaie de faire retourner par exemple un int à la fonction __repr__, le message d'erreur cite __str__.

Code :

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

1
2
3
4
5
6
7
8
9
class ITEM(object):
    def __init__(self):
        pass
 
    def __repr__(self):
        return 12345678
 
p = ITEM()
print p,type(p)

>c:\python25\pythonw -u "repre.py"
Traceback (most recent call last):
File "repre.py", line 9, in <module>
print p,type(p)
TypeError: __str__ returned non-string (type int)
>Exit code: 1

A+

Pfeuh

[Sve@r]

Je suis d'accord mais considérant qu'en python, il y a très souvent une seule manière de bien faire les choses, je préfère utiliser __repr__

Oui. faudra aussi qu'on m'explique dans quel contexte il vaut mieux utiliser "__repr__" ou "__str__" parce que je ne vois pas trop quand choisir l'une ou l'autre.

Les classes Enfant de tes différentes classes possèdent-elle des relations sémantiques entre elles? Ne devraient-elles pas être héritées?

Euh non. Je voulais pas te noyer dans les détails mais bon, puisque t'insistes je vais en dire un peu plus.
J'ai une classe cFreq() pour gérer des fréquences, une classe cDi() pour gérer des durées d'impulsion. Chaque classe possède elle-même une classe cFamille() pour gérer leur famille (il n'y a bien sûr aucun lien mathématique ou logiqueentre la famille d'une fréquence et la famille d'une di) donc non, pas question d'héritage. Bon, avec 2 niveaux hiérarchiques je peux encore gérer. Mais je commence à penser à la suite et je me dis qu'il ne sera pas impossible que dans la famille, j'introduise des classes dédiées à la gestion familiale...

Pourquoi ne pas les sortir de tes définitions?

Là je ne pige pas ce que tu veux dire

Etant inculte en C++,

Euh cette notion de "visibilité" n'est pas spécifique au C++ mais fait partie des notions générales d'un objet. C'est juste qu'en C++, l'écriture de ces classes hiérarchiques peut se faire complètement à gauche du code. Exemple en C++

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// Constructeur cParent1
cParent1::cParent1()
{
    <.. code de cParent1 ..>
}
 
// Constructeur cParent1::cEnfant
cParent1::cEnfant::cEnfant()
{
    <.. code de cEnfant appartenant à cParent1 ..>
}
 
etc...

je ne perçois pas l'utilité pratique de ce genre de structure.

Ben j'espère que mes exemples vont t'aider à mieux voir qu'on peut en avoir besoin...

Je dirais dans un cas comme celui-là qu'il vaudrait mieux créer plusieurs modules. Deux classes peuvent avoir le même nom si elles sont dans des modules différents.

Alors oui, effectivement, je pense aussi à cette possibilité. Un module cParent1.py, un module cParent2.py etc. Mais là, j'ai 2 autres problèmes qui se posent
1) si je veux utiliser cParent1 et cParent2, il me faut faire des import. Et pas question de faire "from ... import *" parce que je vais écraser mon namespace. Donc je serai obligé de faire "import cParent1" et "import cParent2". Et ensuite, partout où j'utilise un objet de cParent1 faudra que je précise "cParent1.objet". Et là, j'avoue que j'ai un peu la flemme de répéter à chaque fois "cParent1" ou "cParent2" parce que j'utilise mes objets un gros paquet de fois. Idem pour des librairies internes à Python. Je préfère faire "from sys import *" et jouer avec les "argv" ou "exit()" plutôt que de faire "import sys" et devoir me taper ensuite des "sys.argv" ou "sys.exit()" à tour de bras. Peut-être que je fais pas comme il faut mais je débute et suis tout seul pour programmer...

2) Si j'utilise 9000 objets, ben mon code commencera par 9000 "import machin" puis "import truc" puis "import chose". Et ça va vite me gonfler aussi de devoir refaire tous ces import à chaque nouveau module qui aura besoin d'accéder à mes objets...