Discussion :

[rambc]

Bonjour.

Soit le code suivant.

Code :

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

1
2
3
class bidon()
   def __init__(self):
       ...

Je voudrais ajouter l'attribut bidon.test en utilisant la chaîne "test". Ceci me permettrait d'ajouter des attributs et leurs valeurs définies à partir d'un dictionnaire.

[kango]

bonjour,

c'est pour ajouter un attribut d'instance ou un attribut de classe ?

pour la classe:

Code :

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

bidon.__dict__[chaine] = valeur

pour l'instance:

Code :

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

1
2
b = bidon()
b.__dict__[chaine] = valeur

ou alors danxs l'init de la classe ?

Code :

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

1
2
def __init__(self):
    self.__dict__[chaine] = value

ou encore, la même chose mais en utilisant setattr:

Code :

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

1
2
3
4
 
setattr(bidon,chaine,value)
setattr(b,chaine,value)
setattr(self,chaine,value)

[wiztricks]

Salut
J'ai peut être pas tout compris mais 'Folder' ci dessous fait un peu cela.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class Folder(dict):
    def __init__(self, **kwds):
        super(Folder, self).__init__(kwds)
        self.__dict__ = self
 
if __name__ == '__main__':
    c = Folder(a=1, b='abc')
    print 'c= ', c
    print 'c.a =', c.a
    print 'c.b =', c.b
    c.c = '123'
    print 'c = ',c

- W

[tyrtamos]

Bonjour,

Peut-être suis-je à côté de la question, mais tant pis:

Python accepte qu'on crée un nouvel attribut de classe 'à la volée', et pourquoi pas, un attribut qui soit un dictionnaire.

Code :

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

1
2
3
4
5
6
7
8
9
 
class Truc(object):
    pass
 
a = Truc()
a.test = {}
a.test['x'] = 123456
print a.test['x']
123456

J'avoue que cette facilité m'a toujours un peu choqué. Mais bon. Pour une fois que c'est utile...

Tyrtamos

[kango]

J'avoue que cette facilité m'a toujours un peu choqué.

moi de même. mais j'avoue avoir lu un article sur le data driven programming dans le dernier HS Linux Mag sur Python qui m'a presque convaincu

(je n'ai pas le mag sous les yeux, je ne me souviens plus du nom de l'auteur)

[wiztricks]

Salut Tyrtamos,

Python accepte qu'on crée un nouvel attribut de classe 'à la volée', et pourquoi pas, un attribut qui soit un dictionnaire

Dans le cas particulier, il s'agit d'un attribut d'instance et non de classe: mais on peut les créer aussi 'à la volée' ou via setattr si on doit transformer une chaine de caractères en noms de variable.

J'avoue que cette facilité m'a toujours un peu choqué. Mais bon. Pour une fois que c'est utile...

Heu?!? C'est quand même ce qui contribue au "dynamique" du langage.
On peut même ajouter ou remplacer des méthodes... Ce qui peut être bien sympa lorsqu'on teste.
Note: __slots__ permet de restreindre quelque peu les ajouts de variables
- W

[tyrtamos]

Bonjour wiztricks,

Heu?!? C'est quand même ce qui contribue au "dynamique" du langage.

Mais le basic avait aussi cette souplesse-là: une faute de frappe et hop: une nouvelle variable est crée sans rien dire... Désolé, je supporte, mais je ne mets pas ça dans les qualités...

Pour ma défense, j'ai beaucoup travaillé en Pascal: j'ai donc été élevé "à la dure", et il doit m'en rester quelques séquelles. .

Tyrtamos

[rambc]

Merci pour ces réponses.

Ce que je cherchais est dans ce code.

Code :

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

1
2
b = bidon()
b.__dict__[chaine] = valeur

Pour rebondir sur le dynamisme de Python, il est parfois dangereux. Il y a a peu j'ai testé des snippets pour pyenchant. Et hop, je me retrouve avec ce que je crois être un gros bug. Je décide de réfléchir au problème, et un peu fatigué je me passe la tête sous l'eau. Et là, révélation, le bug est sous mes yeux dans le mirroir : c'était moi qui avais nommé un fichier tokenize.py alors que pyenchant utilise un module nommé tokenize.
Un petit message pour me dire "Attention, vous avez redéfini tokenize." serait bienvenu. Non ?

[rambc]

Au passage, peut-on créer une sécurité dans un module que l'on tape pour repérer le type de faute que j'ai commise ?

[wiztricks]

Au passage, peut-on créer une sécurité dans un module que l'on tape pour repérer le type de faute que j'ai commise ?

Ben un minimum est d'utiliser pylint ou des IDE tels qu'Eclipse ou Netbeans qui font pas mal de vérifications y compris la complétion des routines appelées.
- W

[rambc]

En fait je cherche une solution en amont que je coderais dans mon module pour prévenir l'utilisateur qu'il a utilisé un nom dont mon module a besoin.

[nardo47]

Salut,

j'avais d'abord penser à un wrapper à placer sur le __dict__ du module, mais pas probant : ce __dict__ n'est pas dispo à l'intérieur du module, à moins de faire beaucoup (trop de) boulot:

Code :

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

1
2
3
4
5
 
from sys import modules
pname = globals()['__name__']
parent = modules[pname]
print parent.__dict__

Ca me parait trop compliqué...
Je rejoins wiztricks, utiliser pylint, et même de façon idéale lancer l'exécution de pylint automatiquement lorsque l'on lance les tests (encore faut-il tester ^^).

[Zavonen]

Je rejoins complètement tyrtamos et kango pour ce qui concerne la création d'attributs de classe 'à la volée'. C'est presque contraire aux fondements de la P.O.O. puisque les objets d'une même classe ne sont pas égaux. Cela m'a également choqué mais il a dû m'arriver une fois ou deux d'en tirer parti (sans gloire).

[nardo47]

C'est presque contraire aux fondements de la P.O.O.

Quels fondements ?
Si je m'en réfère à Wikipedia, la POO est un concept élaboré par Alan Kay, qui est aussi le concepteur de Smalltalk, langage qui en + d'être orienté objet est un des langages les + dynamiques qui soient.

Le principe d'égalité d'instances d'une même classe me semble venir d'une certaine approche de la POO (je dirais la POO statique, à la Java).
Dans l'idéologie Python, la nature des objets qu'on manipule importe peu, du moment qu'ils font ce qu'on leur demande.
Dès lors, ça ne devrait pas choquer d'avoir des objets qui sont "+ égaux" que d'autres.

Ce qui peut faire peur, c'est cette liberté qui autorise tout et n'importe quoi, mais à chacun de prendre ses responsabilités.

[rambc]

Ca me parait trop compliqué...
Je rejoins wiztricks, utiliser pylint, et même de façon idéale lancer l'exécution de pylint automatiquement lorsque l'on lance les tests (encore faut-il tester ^^).

En fait, mon idée était un peu conne car si quelqu'un utilise mon projet et y ajoute un module, c'est a priori qu'il programme en Python, enfin je l'espère... Du coup, les remarques sur pylint et autres sont bien vues.

[fred1599]

Le principe d'égalité d'instances d'une même classe

Je ne vois pas ce que tu veux dire par principe d'égalité, peux-tu m'expliquer s'il te plaît?

Je rejoins complètement tyrtamos et kango pour ce qui concerne la création d'attributs de classe 'à la volée'

Modifier un attribut de classe ou créer un attribut de classe à la volée, c'est pas la même chose? L'attribut existe ou existera non?

Code :

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

1
2
def __init__(self):
    self.__dict__[chaine] = value

Personnellement je n'ai jamais vu ce type de notation, je trouve ça assez déroutant.

[nardo47]

Je ne vois pas ce que tu veux dire par principe d'égalité, peux-tu m'expliquer s'il te plaît?

Je paraphrasais Zavonen qui voulait dire (il me corrigera si je me trompe) que 2 instances d'une même classe doivent avoir exactement les mêmes attributs (au sens large, donc propriétés, méthodes, etc).
En théorie, je suis d'accord avec le principe, appelé le principe de moindre surprise.
Après, vaut-il mieux interdire quelque chose dans un langage ou laisser la responsabilité au codeur de ne pas abuser de ce quelque chose, chacun son choix.

Modifier un attribut de classe ou créer un attribut de classe à la volée, c'est pas la même chose? L'attribut existe ou existera non?

Sauf que quand tu crées un attribut à la volée, tu le crées le + souvent sur une seule instance d'une classe.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
>>> class Spam(object):
        pass
>>> a = Spam()
>>> b = Spam()
>>> a.spam = 12
>>> a.spam
12
>>> b.spam
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
...
AttributeError: 'Spam' object has no attribute 'spam'

Cela dit, maintenant que j'y pense, on peut aussi ajouter un attribut de classe, qui sera donc dispo pour toutes les instances de cette classe, y compris celle qui ont déjà été instanciées.

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
 
>>> class Spam(object):
        pass
>>> a = Spam()
>>> b = Spam()
>>> Spam.spam = 12
>>> a.spam
12
>>> b.spam
12
>>> a.spam = 42
>>> a.spam
42
>>> b.spam
12

Code :

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

1
2
def __init__(self):
    self.__dict__[chaine] = value

Personnellement je n'ai jamais vu ce type de notation, je trouve ça assez déroutant.

Comme tout chose que l'on ne connaît pas :

• la boucle for en C ;
• les compréhensions de listes ;
• les générateurs et l'expression yield ;
• les closures ;
• les fonctions anonymes ;
• le passage par référence ;
• pas mal de design patterns ;
• pleins d'autres choses.

Tout est question d'habitude, voire de convention.

[Zavonen]

Je paraphrasais Zavonen qui voulait dire (il me corrigera si je me trompe) que 2 instances d'une même classe doivent avoir exactement les mêmes attributs (au sens large, donc propriétés, méthodes, etc).

C'est exactement ce que je voulais dire. Pas de démenti donc.

[eyquem]

un peu fatigué je me passe la tête sous l'eau. Et là, révélation, le bug est sous mes yeux dans le mirroir : c'était moi qui avais nommé un fichier tokenize.py

ouah, quel art de la narration !

L’orthographe, c’est moins ça.

J'avoue que cette facilité m'a toujours un peu choqué. Mais bon. Pour une fois que c'est utile...

moi de même. mais j'avoue avoir lu un article sur le data driven programming dans le dernier HS Linux Mag sur Python qui m'a presque convaincu

Je rejoins complètement tyrtamos et kango pour ce qui concerne la création d'attributs de classe 'à la volée'. C'est presque contraire aux fondements de la P.O.O. puisque les objets d'une même classe ne sont pas égaux. Cela m'a également choqué mais il a dû m'arriver une fois ou deux d'en tirer parti (sans gloire).

Je distingue deux ordres de critique dans ces propos:
- c’est choquant
- c’est inutile




Je ne comprends pas qu’on puisse trouver choquante cette possibilité. J’avoue qu’au début, je l’ai trouvé légèrement surprenante. Mais j’ai rapidement considéré que je devais intégrer cette information au même titre que plein d’autres qui constituent le langage, faisant aux confiance développeurs du langage pour savoir ce qu’il font.



Si je comprends bien tyrtamos, ce qui le choque est que Python laisse la possibilité au programmeur de faire des bêtises.
Je pense que la quantité de risques courus est proportionnelle aux possibilités. Augmenter la sécurité, c'est en restreignant les possibilités, ce serait brimer la liberté
Chacun a sa réaction face à la problématique. Celle-ci en est une autre:

Ce qui peut faire peur, c'est cette liberté qui autorise tout et n'importe quoi, mais à chacun de prendre ses responsabilités.

Pour ma part, je n’ai pas d’avis général, mais sur la définition d’attributs à la volée, je trouverais dommage et pour tout dire incompréhensible, de ne pas disposer de cette possibilité.

Après tout, qui, en voyant ceci:

Code :

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

1
2
3
4
5
lune phobos
patisserie 1800
======================
lune phobos
patisserie 1800

est capable de dire que ça a été obtenu par

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
class A:
    st = 'lune'
    def __init__(self,x):
        self.ixe = x
 
a = A('phobos')
print A.st,a.ixe
 
A.st,a.ixe  = 'patisserie',1800
print A.st,a.ixe
 
print '======================'
 
class A:
    pass
 
a = A()
A.st,a.ixe = 'lune','phobos'
print A.st,a.ixe
 
A.st,a.ixe  = 'patisserie',1800
print A.st,a.ixe

Comme l’a écrit wiztricks, __slots__ permet de prévenir des erreurs d’écriture du genre a.jxe = 90 qui créerait par erreur un attribut jxe au lieu de modifier ixe.
On peut aussi se faire sa gendarmerie personnelle en employant __setattr__()

Python ne manque pas de possibilités. Personnellement, tant que j’ai le sentiment de pouvoir progresser toujours plus en Python et de pouvoir maitriser de mieux en mieux les pièges possibles, je préfère avoir à ma disposition de nombreuses possibilités.



Ça revient à dire idem que:

C'est quand même ce qui contribue au "dynamique" du langage.

Le data driven programming évoqué par kango en est un exemple.

J’en ai un autre, bien que je ne comprenne pas tout:

Not many are aware of this feature, but Python's functions (and methods) can have attributes.
http://stackoverflow.com/questions/3...ses-and-abuses

Here are some examples of what you can do with this feature.
http://www.python.org/dev/peps/pep-0232/

cf
http://mail.python.org/pipermail/pyt...il/003364.html

Ce qui répond au pseudo-argument d’inutilité.









Pour ce qui est de l’autre argument de Zavonen pour trouver choquante cette possibilité, je réagis comme

Envoyé par Zavonen
C'est presque contraire aux fondements de la P.O.O.

Quels fondements ?

Le principe d'égalité d'instances d'une même classe

Je ne vois pas ce que tu veux dire par principe d'égalité, peux-tu m'expliquer s'il te plaît?

Je paraphrasais Zavonen qui voulait dire (il me corrigera si je me trompe) que 2 instances d'une même classe doivent avoir exactement les mêmes attributs (au sens large, donc propriétés, méthodes, etc).

C'est exactement ce que je voulais dire. Pas de démenti donc.

Pourquoi « doivent avoir exactement les mêmes attributs » ?!?

Je trouve rudement bizarre de reprocher à Python de doter les objets d’une “feature“ qui ne peut qu’accroître la souplesse de leur utilisation dans un paradigme PO.

(je n'ai pas le mag sous les yeux, je ne me souviens plus du nom de l'auteur)

Python, le serpent très dynamique.
Jean Gabès
Hors-série Linux Magazine no 49 - Août-septembre 2010

Code :

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

1
2
def __init__(self):
    self.__dict__[chaine] = value

Personnellement je n'ai jamais vu ce type de notation, je trouve ça assez déroutant.

Il va falloir t’y faire. Car Python fonctionne (on me corrigera si je me trompe) sur la base d’espaces de noms dans tous les sens: les espaces de noms sont implémentés comme des dictionnaires, et Python passe son temps à créer des espaces de noms attachés à certaines catégories Python (module, classe, fonction, en-tête de boucle for, instances de classes, etc...) , à inscrire et désinscrire des items dans ces espaces de noms, et à détruire des espaces de noms (par exemple en sortant d’une fonction).

L’inscription dans un espace de noms consiste à
enregistrer le nom d’un objet sous forme de chaîne comme une clé de l’espace de nom
et à y associer (to bind) l’objet correspondant comme valeur de l’espace de nom.

The following constructs bind names: formal parameters to functions, import statements, class and function definitions (these bind the class or function name in the defining block), and targets that are identifiers if occurring in an assignment, for loop header, in the second position of an except clause header or after as in a with statement. The import statement of the form from ... import * binds all names defined in the imported module, except those beginning with an underscore. This form may only be used at the module level.

A target occurring in a del statement is also considered bound for this purpose (though the actual semantics are to unbind the name).

http://docs.python.org/reference/exe...ng-and-binding

L’attribut __dict__ qui permet d’accéder à l’espace de noms d’une entité (classe, fonction, objet, module...) est fort utile à connaître.

La fonction dir() , qui fonctionne différemment selon qu’on lui fournit un argument ou non, et selon que l’argument est un objet ayant une méthode __dir__() ou non) permet d’obtenir la liste des noms des attributs (au sens large: données menbres aussi bien que fonctions) de l’argument.
dir(arg) elle renvoie en quelque sorte arg.__dict__.keys() et est fort utile itou.

[fred1599]

Bon j'avais un peu de mal à comprendre ce topic, et c'est vrai que d'habitude en regardant la longueur des posts d'eyquem, je suis fatigué avant de les lire. Mais là je dois avouer que j'ai bu tes "paroles".

L’attribut __dict__ qui permet d’accéder à l’espace de noms d’une entité (classe, fonction, objet, module...) est fort utile à connaître.

La fonction dir() , qui fonctionne différemment selon qu’on lui fournit un argument ou non, et selon que l’argument est un objet ayant une méthode __dir__() ou non) permet d’obtenir la liste des noms des attributs (au sens large: données menbres aussi bien que fonctions) de l’argument.
dir(arg) elle renvoie en quelque sorte arg.__dict__.keys() et est fort utile itou.

J'y pense jamais à ces espaces de nom qui sont très importants.