RLock : __owner est un entier ?

Bonjour,

Pour mes besoins, j'ai dû écrire une classe dérivée de _RLock.

Mais ceci génère des Attribute Error, comme quoi un entier n'a pas de méthode is_alive.

Code:

---

1 2 3 4 5 6 7 8

class PyWallELock(threading._RLock): def acquire(self, blocking=1): try: if self._RLock__owner != None and not self._RLock__owner.is_alive(): self.__owner=threading.current_thread() except AttributeError: print "%i" % self._RLock__owner threading._RLock.acquire(self)

---

Et ce code donne en sortie, effectivement, un paquet de nombres entiers, du style :
140268629804816
140268650829584
140268629804816
140268650829584
140268629804816
140268629804816
140268650829584
140268650829584
140268629804816
140268650829584
140268629804816
Ou bien, lorsque je relance le script :
140000078051088
140000118101776
140000078051088
140000134887184
140000118101776
140000118101776
140000069658384
140000078051088
140000134887184

J'ai scruté l'implémentation de _RLock, mais je ne comprend pas...

J'utilise Python2.6

Merci d'avance,
ProgVal

Oh la la tu peux vraiment pas faire autrement ?

Non seulement tu importes une classe qui n'est pas exposée par défaut (from threading import * ne l'importe pas) mais en plus tu accèdes à un attribut "privé" de la classe _RLock (__owner, qui est renommé _RLock__owner a l'extérieur de la classe).

Dans ton code, je vois des références à _RLock__owner et à __owner, c'est normal ? Ca devrait pas être _RLock__owner partout ?

C'est sans doute pas lié à ton problème, mais l'argument "blocking" ne fait rien. Tu devrais pas aussi le passer à threading._RLock.acquire ?

Bonjour,

Dans le code du module threading, je n'ai pas vu de '_RLock__owner'. Il ne manquerait pas un point entre les 2 : '_RLock.__owner' ?

Tyrtamos

Merci à vous.

Citation:

---

Envoyé par tyrtamos

Dans le code du module threading, je n'ai pas vu de '_RLock__owner'. Il ne manquerait pas un point entre les 2 : '_RLock.__owner' ?

---

Non justement, c'est un mécanisme de "name mangling" propre à Python. Quand un attribut d'une classe commence par deux underscores, son nom à l'extérieur de la classe devient _(nom de la classe)__(nom de l'attribut). Comme Python n'a pas de contrôle d'accès aux attributs (tout est public), c'est censé fournir un minimum de précaution contre les modifications accidentelle.

Exemple:

Code:

---

1 2 3 4 5 6

>>> class A: ... public = 0 ... __private = 0 ... >>> dir(A) ['_A__private', '__doc__', '__module__', 'public']

---

Informellement, je dirais que les conventions de nommage des attributions en Python est la suivante (cela vaut aussi pour les méthodes):

attribut --> public, fait partie de l'API, peut être une property
_attribut --> pas censé être accédé par les clients lors d'une utilisation "normale", souvent pas documenté, mais des utilisations avancées (par exemple hériter de la classe) pourrait l'utiliser
__attribut --> pas touche ! Je l'aurais déclaré privé si ça existait en Python.

Arf, c'est bien ce que je me disais...

J'ai fini par recoder moi-même (et au passage, j'ai ajouté une sécurité quant à la multi-écriture simultannée des ConfigParser)

Code:

---

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

class PyWallEConfigParser(SafeConfigParser):   def __init__(self): raise Exception("Ce constructeur ne doit pas être appellé")   def __init__(self, filename): self._waiting=0 self._owner=None SafeConfigParser.__init__(self) self._filename=filename if not os.path.isfile(filename): file(filename, 'a') self._file=file(filename, 'r+U') self.readfp(self._file)   def acquire(self): self._waiting=self._waiting+1 while self._owner != None and self._owner.is_alive(): time.sleep(0.1) self._owner=threading.current_thread() return True   def release(self): if not self._owner is threading.current_thread(): return False if self._waiting == 1: # Si on est le seul en attente self._file.seek(0) self.write(self._file) self._waiting=self._waiting-1 self._owner=None

---