En effet, en effectue ensuite un nombre important de fois l'opération i in nonfree.
Avec des liste l'opération est en O(n) alors qu'elle est en O(1) avec des set
D'une façon général, on s'assure que tous les locks concernant un cransLdapObject
sont bien mis avec l'identifiant de lock cransLdapObject.lockId.
Avant d'entrer dans le context manager du cransLdapObject, on fait bien attention
d'intercepter les exceptions pouvant être levée pour libérer les locks potentiellement
déjà posés avant de propager l'exception.
Si on essayer d'appeler une methode d'enregistrement (.save() .delete() .create()) sans
utiliser un context manager, on affiche un warning sur stderr.
À terme ça serait bien de n'utiliser que des context manager pour être sûr qu'on ne
laisse pas de lock traîner dans la base de donnée.
Il faut bien sûr faire attention de bien ajouter les lock avec l'identifiant cransLdapObject.lockId
puisqu'on se base là dessus pour les libérer.
Si on a utiliser une context manager, en en sortant, on rend le cransLdapObject read only
(de façon douce en modifiant le cransLdapObject.mode et de façon force en changeant les methodes
save create delete pour lever l'exception EnvironmentError("Hors du context, impossible de faire des écritures"))
C'est un peu moche comme on s'est efforcé que dans lc_ldap tout soit un unicode et que
unicode n'a pas de sens pour un objet binaire. Avec le champ python_type = str sur les
attributs bianire, ça a tout de même l'air d'aller.
En effet, python n'aime pas que les objets multables soient utilisé dans des sets
ou comme clef de dictionnaire, du coup, on va essayer de ne pas le contrarier.
De toute façon, c'est logique vu que la valeur du hash change si on édite l'objet.
Pour ça on est obligé (si on utilise pyparsing) de générer la liste de tous les charactère unicode.
Daniel fait remarquer que ça n'est pas joli d'instancier une chaine de 63Ko quand on veux parser quelque chose.
On ne le fait tout de même que de façon paresseuse la première fois que l'on a besoin de parser quelquechose
(dans filter2, filter3 est juste un proof of concept).
Pour faire du human_to_ldap, on peut utiliser directement la fonction de filter.py qui n'est pas impacté
par le problème, mais pour ressucite, on a pour le moment pas le choix puisqu'on utilise la fonction
human_to_list qui n'est fournie que dans les modules filter2 et filter3.
À noter que __getattr__ n'est appelé que si l'attribut n'existe pas déjà.
Ça permet d'utiliser l'objet Attr comme sa valeur pour la plupart des opération
de lecture simple.
J'ai fait exprès de ne pas surcharger __setattr__, parce que sinon, on ne sait
plus trop ce qui va être affecté. J'estime que les écriture doivent être traités au
cas par cas comme pour blacklist ou pour article.
Au lieu d'être obligé de faire à chaque fois obj[attr] = obj[attr] + [val]
on peut faire directement obj[attr].append(val).
Si on affecte obj[attr] à une variable (l=obj[attr])
et que l'on modifie la variable (l.append(val)), a la fois la variable et obj[attr] sont modifié
et maintenue à jour.
Attention toutefois :
l1 = obj[attr]
l2 = obj[attr]
l1 == l2 <=> True
l1.append(val)
l1 == obj[attr] <=> True
l1 == l2 <=> False
l2 == obj[attr] <=> False
et l2.append(val) lèvera une exception.
