Le message "dictionary changed size during iteration" m'a un poil déçu, sur
l'aspect dynamique des itérations.
Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voiture pour
ça...
C'est plutôt histoire de bavarder.
Le message "dictionary changed size during iteration" m'a un poil déçu, sur l'aspect dynamique des itérations. Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voiture pour ça... C'est plutôt histoire de bavarder.
Tu as la solution d'utiliser une version qui n'itère pas sur le dico lui-même, mais sur ses clés/valeurs/couples (iteritems -> items & Co).
Sinon, ça me parait correct (et même bien) que Python te prévienne que pendant une itération sur le dictionnaire, celui-ci a été modifié. Comment doit se comporter l'itérateur? En cas d'ajout? En cas de suppression? En cas de modification? Pas simple la sémantique d'une itération sur quelque chose qui se modifie...
Perso, j'ai déjà eu du code d'itération sur des listes que je savaient pouvoir être modifiées par d'autres threads, et ça donnait: for x in maliste[:] : ... (sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
A+
Laurent.
Do Re Mi chel La Si Do wrote:
Bonsoir !
Le message "dictionary changed size during iteration" m'a un poil déçu, sur
l'aspect dynamique des itérations.
Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voiture pour
ça...
C'est plutôt histoire de bavarder.
Tu as la solution d'utiliser une version qui n'itère pas sur le dico
lui-même, mais sur ses clés/valeurs/couples (iteritems -> items & Co).
Sinon, ça me parait correct (et même bien) que Python te prévienne que
pendant une itération sur le dictionnaire, celui-ci a été modifié.
Comment doit se comporter l'itérateur? En cas d'ajout? En cas de
suppression? En cas de modification? Pas simple la sémantique d'une
itération sur quelque chose qui se modifie...
Perso, j'ai déjà eu du code d'itération sur des listes que je savaient
pouvoir être modifiées par d'autres threads, et ça donnait:
for x in maliste[:] :
...
(sachant que la copie de liste est une opération atomique au niveau de
l'interpréteur).
Le message "dictionary changed size during iteration" m'a un poil déçu, sur l'aspect dynamique des itérations. Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voiture pour ça... C'est plutôt histoire de bavarder.
Tu as la solution d'utiliser une version qui n'itère pas sur le dico lui-même, mais sur ses clés/valeurs/couples (iteritems -> items & Co).
Sinon, ça me parait correct (et même bien) que Python te prévienne que pendant une itération sur le dictionnaire, celui-ci a été modifié. Comment doit se comporter l'itérateur? En cas d'ajout? En cas de suppression? En cas de modification? Pas simple la sémantique d'une itération sur quelque chose qui se modifie...
Perso, j'ai déjà eu du code d'itération sur des listes que je savaient pouvoir être modifiées par d'autres threads, et ça donnait: for x in maliste[:] : ... (sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
A+
Laurent.
Eric Deveaud
Laurent Pointal wrote:
(sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
tu peux détailler stp. j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie d'une liste.
Eric
-- J'ai mplayer2 qui fait des siennes Quand je veux téléchargé une bande-annonce ou autre vidéo. mplayer2 se met en lecture. En conclusion mon micro ne télécharge pas et mon patron gueule comme un putoi. -+- MN in <http://neuneu.mine.nu/> - Vidéo et des bas -+-
Laurent Pointal wrote:
(sachant que la copie de liste est une opération atomique au niveau de
l'interpréteur).
tu peux détailler stp.
j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie
d'une liste.
Eric
--
J'ai mplayer2 qui fait des siennes Quand je veux téléchargé une
bande-annonce ou autre vidéo. mplayer2 se met en lecture. En conclusion
mon micro ne télécharge pas et mon patron gueule comme un putoi.
-+- MN in <http://neuneu.mine.nu/> - Vidéo et des bas -+-
(sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
tu peux détailler stp. j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie d'une liste.
Eric
-- J'ai mplayer2 qui fait des siennes Quand je veux téléchargé une bande-annonce ou autre vidéo. mplayer2 se met en lecture. En conclusion mon micro ne télécharge pas et mon patron gueule comme un putoi. -+- MN in <http://neuneu.mine.nu/> - Vidéo et des bas -+-
mattdo
On 2005-11-17, Eric Deveaud wrote:
Laurent Pointal wrote:
(sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
tu peux détailler stp. j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie d'une liste.
Euh une question un peu OT, opération atomique == opération non couteuse?
Moi j'interprète le post de Laurent, plutot dans le sens: opération atomique == opération qui ne peut etre perturbée. Bref avec une sorte de lock ou autre pour que les datas de la liste source ne soient pas modifies pendant la copie.
Enfin effectivement, il me semble qu'il est plutot bon d'itérer sur une liste stable...
-- mattdo
On 2005-11-17, Eric Deveaud <edeveaud@pasteur.fr> wrote:
Laurent Pointal wrote:
(sachant que la copie de liste est une opération atomique au niveau de
l'interpréteur).
tu peux détailler stp.
j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie
d'une liste.
Euh une question un peu OT, opération atomique == opération non
couteuse?
Moi j'interprète le post de Laurent, plutot dans le sens: opération
atomique == opération qui ne peut etre perturbée. Bref avec une sorte
de lock ou autre pour que les datas de la liste source ne soient pas
modifies pendant la copie.
Enfin effectivement, il me semble qu'il est plutot bon d'itérer sur une
liste stable...
(sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
tu peux détailler stp. j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie d'une liste.
Euh une question un peu OT, opération atomique == opération non couteuse?
Moi j'interprète le post de Laurent, plutot dans le sens: opération atomique == opération qui ne peut etre perturbée. Bref avec une sorte de lock ou autre pour que les datas de la liste source ne soient pas modifies pendant la copie.
Enfin effectivement, il me semble qu'il est plutot bon d'itérer sur une liste stable...
-- mattdo
remi_inconnu
Bonsoir !
Le message "dictionary changed size during iteration" m'a un poil déç u, sur l'aspect dynamique des itérations. Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voitu re pour ça... C'est plutôt histoire de bavarder.
@-salutations
Michel Claveau Personnellement je ne trouve pas bien normal que l'on modifie un
dictionnaire pendant qu'on le consulte. Si c'est un autre thread qui le modifie, un mutex est de rigueur, si c'est dans le parcours, un changement d'algorithme s'impose. Si tu as l'occasion d'utiliser d'autres langages comme le C++ avec les STL, tu risques au mieux de ne pas voir le problème, au pire un crash bien sale de l'application, dans tous les cas il vaut mieux éviter une modification durant la consultation, et c'est une chance que python t'avertisse...
Bonsoir !
Le message "dictionary changed size during iteration" m'a un poil déç u, sur
l'aspect dynamique des itérations.
Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voitu re pour
ça...
C'est plutôt histoire de bavarder.
@-salutations
Michel Claveau
Personnellement je ne trouve pas bien normal que l'on modifie un
dictionnaire pendant qu'on le consulte. Si c'est un autre thread qui le
modifie, un mutex est de rigueur, si c'est dans le parcours, un
changement d'algorithme s'impose. Si tu as l'occasion d'utiliser
d'autres langages comme le C++ avec les STL, tu risques au mieux de ne
pas voir le problème, au pire un crash bien sale de l'application,
dans tous les cas il vaut mieux éviter une modification durant la
consultation, et c'est une chance que python t'avertisse...
Le message "dictionary changed size during iteration" m'a un poil déç u, sur l'aspect dynamique des itérations. Bon, ce n'est pas un problème grave ; je ne vais pas brûler une voitu re pour ça... C'est plutôt histoire de bavarder.
@-salutations
Michel Claveau Personnellement je ne trouve pas bien normal que l'on modifie un
dictionnaire pendant qu'on le consulte. Si c'est un autre thread qui le modifie, un mutex est de rigueur, si c'est dans le parcours, un changement d'algorithme s'impose. Si tu as l'occasion d'utiliser d'autres langages comme le C++ avec les STL, tu risques au mieux de ne pas voir le problème, au pire un crash bien sale de l'application, dans tous les cas il vaut mieux éviter une modification durant la consultation, et c'est une chance que python t'avertisse...
Laurent Pointal
Eric Deveaud wrote:
Laurent Pointal wrote:
(sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
tu peux détailler stp. j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie d'une liste.
Le fameux GIL (Global Interpreter Lock) de C-Python [1].
Rapidement, les threads Python, lorsqu'ils interprètent les scripts compilés en byte-code, utilisent un mutex global -le GIL- qui protège l'ensemble des objets Python (et en Python tout est objet) contre les accès concurrents. Chaque thread acquière le GIL, effectue une série [2] d'opérations "atomiques", puis relache le GIL [3]. Et donc, la copie d'une liste Python est une opération atomique de l'interpréteur - même si elle peut être coûteuse au niveau de la machine.
Voilà.
A+
Laurent.
[1] Pour Jython, je n'en sais rien. [2] Cf sys.getcheckinterval(). [3] Les éléments de code compilés natif, lorsqu'ils n'ont pas à accéder aux objets Python (calculs, entrées/sorties, renvoi vers des bibliothèques de GUI), relachent généralement le GIL, permettant à l'interpréteur de donner la main à un autre thread, et ré-acquièrent le GIL lorsqu'ils ont à nouveau besoin d'accéder à la machinerie Python.
Eric Deveaud wrote:
Laurent Pointal wrote:
(sachant que la copie de liste est une opération atomique au niveau de
l'interpréteur).
tu peux détailler stp.
j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie
d'une liste.
Le fameux GIL (Global Interpreter Lock) de C-Python [1].
Rapidement, les threads Python, lorsqu'ils interprètent les scripts
compilés en byte-code, utilisent un mutex global -le GIL- qui protège
l'ensemble des objets Python (et en Python tout est objet) contre les
accès concurrents.
Chaque thread acquière le GIL, effectue une série [2] d'opérations
"atomiques", puis relache le GIL [3]. Et donc, la copie d'une liste
Python est une opération atomique de l'interpréteur - même si elle peut
être coûteuse au niveau de la machine.
Voilà.
A+
Laurent.
[1] Pour Jython, je n'en sais rien.
[2] Cf sys.getcheckinterval().
[3] Les éléments de code compilés natif, lorsqu'ils n'ont pas à accéder
aux objets Python (calculs, entrées/sorties, renvoi vers des
bibliothèques de GUI), relachent généralement le GIL, permettant à
l'interpréteur de donner la main à un autre thread, et ré-acquièrent le
GIL lorsqu'ils ont à nouveau besoin d'accéder à la machinerie Python.
(sachant que la copie de liste est une opération atomique au niveau de l'interpréteur).
tu peux détailler stp. j'avoue avoir du mal à concevoir une opération non couteuse pour la recopie d'une liste.
Le fameux GIL (Global Interpreter Lock) de C-Python [1].
Rapidement, les threads Python, lorsqu'ils interprètent les scripts compilés en byte-code, utilisent un mutex global -le GIL- qui protège l'ensemble des objets Python (et en Python tout est objet) contre les accès concurrents. Chaque thread acquière le GIL, effectue une série [2] d'opérations "atomiques", puis relache le GIL [3]. Et donc, la copie d'une liste Python est une opération atomique de l'interpréteur - même si elle peut être coûteuse au niveau de la machine.
Voilà.
A+
Laurent.
[1] Pour Jython, je n'en sais rien. [2] Cf sys.getcheckinterval(). [3] Les éléments de code compilés natif, lorsqu'ils n'ont pas à accéder aux objets Python (calculs, entrées/sorties, renvoi vers des bibliothèques de GUI), relachent généralement le GIL, permettant à l'interpréteur de donner la main à un autre thread, et ré-acquièrent le GIL lorsqu'ils ont à nouveau besoin d'accéder à la machinerie Python.
Do Re Mi chel La Si Do
Salut !
J'ai dit que c'était pour bavarder, et me voilà servi !
Il y a des moments où je rejoindrais presque l'opinion de ceux qui disent que l'informatique est en phase de régression.
J'ai l'impression que l'on est revenu 20 ans en arrière, à parler des verrouillages optimistes ou pessimistes, du domaine d'application des verrous (leurs types), du comportement ACID des transactions, de leur niveau d'isolement, de la normalisation/dénormalisation des dictionnaires, etc.
Ça va être chouette : on va s'étriper, virtuellement, à grand coups d'opinions toutes faites, émaillées de citations d'illustres inconnus.
Un rêve de troll, finalement...
@-salutations
Michel Claveau
Salut !
J'ai dit que c'était pour bavarder, et me voilà servi !
Il y a des moments où je rejoindrais presque l'opinion de ceux qui disent
que l'informatique est en phase de régression.
J'ai l'impression que l'on est revenu 20 ans en arrière, à parler des
verrouillages optimistes ou pessimistes, du domaine d'application des
verrous (leurs types), du comportement ACID des transactions, de leur niveau
d'isolement, de la normalisation/dénormalisation des dictionnaires, etc.
Ça va être chouette : on va s'étriper, virtuellement, à grand coups
d'opinions toutes faites, émaillées de citations d'illustres inconnus.
J'ai dit que c'était pour bavarder, et me voilà servi !
Il y a des moments où je rejoindrais presque l'opinion de ceux qui disent que l'informatique est en phase de régression.
J'ai l'impression que l'on est revenu 20 ans en arrière, à parler des verrouillages optimistes ou pessimistes, du domaine d'application des verrous (leurs types), du comportement ACID des transactions, de leur niveau d'isolement, de la normalisation/dénormalisation des dictionnaires, etc.
Ça va être chouette : on va s'étriper, virtuellement, à grand coups d'opinions toutes faites, émaillées de citations d'illustres inconnus.
Un rêve de troll, finalement...
@-salutations
Michel Claveau
Do Re Mi chel La Si Do
Bonjour !
D'accord pour l'importance de l'atomicité des opérations utilisées. Mais il manque les notions de cohérence, d'isolation (quoique, avec le GIL, on est pas mal), et de durabilité. Notamment si l'opération en question ne s'est pas bien passée.
@-salutations
Michel Claveau
Bonjour !
D'accord pour l'importance de l'atomicité des opérations utilisées. Mais il
manque les notions de cohérence, d'isolation (quoique, avec le GIL, on est
pas mal), et de durabilité. Notamment si l'opération en question ne s'est
pas bien passée.
D'accord pour l'importance de l'atomicité des opérations utilisées. Mais il manque les notions de cohérence, d'isolation (quoique, avec le GIL, on est pas mal), et de durabilité. Notamment si l'opération en question ne s'est pas bien passée.
@-salutations
Michel Claveau
remi_inconnu
Désolé si j'ai été un peu sec, je m'excuse... ;-)
Mais je veux bien revenir 20 ans en arrière et retrouver mon atari ou mon ZX 81 pour programmer des soirées entières en assembleur, quoique maintenant après avoir gouté Python j'aurai un peu de mal, et puis avoir de nouveau 20 ans, ce serai le rêve...
;-)
Désolé si j'ai été un peu sec, je m'excuse... ;-)
Mais je veux bien revenir 20 ans en arrière et retrouver mon atari ou
mon ZX 81 pour programmer des soirées entières en assembleur, quoique
maintenant après avoir gouté Python j'aurai un peu de mal, et puis
avoir de nouveau 20 ans, ce serai le rêve...
Mais je veux bien revenir 20 ans en arrière et retrouver mon atari ou mon ZX 81 pour programmer des soirées entières en assembleur, quoique maintenant après avoir gouté Python j'aurai un peu de mal, et puis avoir de nouveau 20 ans, ce serai le rêve...
;-)
Hervé Cauwelier
et puis avoir de nouveau 20 ans, ce serai le rêve...
Des boutons et pas d'argent ? ;-)
-- Hervé Cauwelier http://www.oursours.net/
et puis avoir de nouveau 20 ans, ce serai le rêve...
