Discussion :

[plxpy]

Bonjour

Il y a quelques temps de cela, j'ai écrit une classe dérivée, au sens POO, de dict pour disposer de dictionnaires qui seraient, au niveau des clés de type chaine de caractères, insensibles à la casse (minuscules, majuscules : même combat).

Le but était de ne pas truffer mon code d'appels à upper, lower, isupper, etc... mais de centraliser la gestion de ce "problème" à un seul et même endroit. Ca me permet de pouvoir faire ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
>>> from cidict import cidict
>>>
>>> cid = cidict({'un':1,'Deux':2})
>>>
>>> cid
{'un': 1, 'deux': 2}
>>> cid['DEUX']
2
>>>
>>> 'Un' in cid
True

J'ai repris ces derniers jours le code et ai cherché s'il n'existait pas un "truc" standard (fourni avec l'interpréteur ou dans PyPI). Je suis tombé sur le module UserDict qui propose, entre autres, les classes UserDict et IterableUserDict.

J'ai regardé le code correspondant (version 2.6) et je ne saisis pas l'apport de ces classes par rapport à une dérivation directe de dict. Côté intérêt didactique/pédagogique, pas de problème (ça m'a permis de compléter mon code initial). Mais l'inclure dans la distribution Python elle-même, je ne comprends pas. Qu'est-ce que je loupe ? Instancier directement ces classes n'a (je pense) aucun intérêt et il faut obligatoirement les dériver. Pourquoi alors passer par cet intermédiaire et refaire, peu ou prou, la même chose que si l'on dérivait dict ?

[PauseKawa]

Bonjour,

Ce n'est qu'un wrapper de l'objet dico. Ou est le souci ?
Dans ce sens quel est l’intérêt de shutil ?
Au moins le code est juste.

@+

[fred1599]

Il me semble que Userdict était surtout utilisé parce-qu'on ne pouvait pas hériter de dict. Maintenant qu'on peut le faire je ne suis pas sûr que se soit encore utile.

[wiztricks]

Salut,

J'ai repris ces derniers jours le code et ai cherché s'il n'existait pas un "truc" standard (fourni avec l'interpréteur ou dans PyPI). Je suis tombé sur le module UserDict qui propose, entre autres, les classes UserDict et IterableUserDict.

Les "dict" étant des objets de base très utilisés, ils ont du évoluer dans le temps.
Et les développeurs Python ayant le soucis de réaliser de nouvelles fonctionnalités dans casser les anciens codes, ont du être imaginatifs et proposer des solutions qui, si elles faisaient sens, compte tenu des fonctionnalités de Python "à l'époque" sont aujourd'hui décalées.

Il est rare que la contrainte "Sans casser les anciens codes" soit perpétuelle: on profite de la sortie d'une version majeure pour éventuellement "déprécier" de telles fonctionnalités... En espérant que le nombre de code impactés sera réduit.

Ceci dit la documentation me semble assez claire sur le sujet:

This module also defines a class, UserDict, that acts as a wrapper around dictionary objects. The need for this class has been largely supplanted by the ability to subclass directly from dict (a feature that became available starting with Python version 2.2). Prior to the introduction of dict, the UserDict class was used to create dictionary-like sub-classes that obtained new behaviors by overriding existing methods or adding new ones.
...
For backward compatibility, instances of UserDict are not iterable.

class UserDict.IterableUserDict([initialdata])¶
Subclass of UserDict that supports direct iteration (e.g. for key in myDict).

=> Ca existe et de vieux codes peuvent utiliser ces classes en v2. Si vous écrivez de nouveaux codes, vous pouvez/devez à partir de 2.2, ignorez cela et sous-classez dict directement.

- W

[dividee]

La difficulté en héritant directement d'un built-in comme dict est de déterminer quelles méthodes il est nécessaire de redéfinir. La documentation n'explicite pas quelles méthodes sont implémentées en termes de quelles autres. Par exemple, on pourrait penser que get utilise __getitem__, et qu'il suffit donc de redéfinir cette dernière, mais il se trouve que ce n'est pas le cas. L'inverse n'est pas vrai non plus; il faut donc redéfinir les deux méthodes. Et qu'en est-il de __contains__ ?

Pour éviter ce genre de piège, et réduire le nombre de méthodes à redéfinir, il vaut mieux passer par les ABCs (abstract base classes) du modules collections. En l'occurence, collections.MutableMapping. Là, les méthodes à redéfinir sont clairement explicitées. Dans ce cas-ci: __iter__, __len__, __getitem__, __setitem__, __delitem__. Au moins, on est sûr de ne rien oublier (Python le signalera si on en oublie une). Selon les cas, on peut souhaiter redéfinir d'autres méthodes pour optimiser les performances, mais ce n'est pas obligatoire.

[plxpy]

Merci pour vos réponses.

Effectivement, je suis passé un peu vite sur le début de la documentation (trop pressé de comprendre comment ça marchait) qui indique que depuis la version 2.2 on peut directement dériver dict. Les contraintes de compatibilité ascendante font le reste. D'ailleurs elles semblent perdurer car en version 3, même si elles ont été "rétrogradées" dans le module collections, ces classes existent toujours.

Par contre, je ne suis pas d'accord pour le parallèle avec shutil : shutil, même si on peut tout réécrire avec les "briques" de base, apporte quelque chose. (Iterable)UserDict (excepté qu'elles paliaient l'impossibilité de dériver dict avant la 2.2) n'apportent rien : tout le travail qu'on doit faire pour surcharger les méthodes (les "normales" et les spéciales) quand on dérive dict doit aussi être fait avec ces classes. Ce sont donc des (sur)couches "à blanc"/"neutres".

Et pour le module collections, oui j'ai vu. Ca semble assez élaboré, peut-être trop (inutilement trop) pour "mes" dictionnaires insensibles à la casse. J'avoue que le côté dérivation de dict me va bien car, alors, on peut utiliser ces dictionnaires, comme les autres et ils "résistent" à des choses du style "isinstance(d,dict)". Je vais regarder ça de plus près, ne serait-ce que pour, éventuellement, bénéficier de l'aide pour redéfinir telle ou telle méthode (j'en avais d'ailleurs oublié dans mon premier jet et c'est l'étude du code de UserDict qui m'y a fait penser).

Encore merci

[PauseKawa]

Par contre, je ne suis pas d'accord pour le parallèle avec shutil : shutil, même si on peut tout réécrire avec les "briques" de base, apporte quelque chose.

L'exemple est mal choisi en effet, même si shutil 'apporte quelque chose de plus' de même que le sujet présent.

L'utilité est confirmée par le passage dans collections et non un deprecated ?
Sans doute, ou pas: Comme le dit wiztricks on s'attaque ici à un 'conteneur' (boite) plus que très usité. Passage en douceur sans doute.