Discussion :

[jingenbl]

Heapq prend en charge des n-uples ou des listes . Le tri s'effectue sur l'élément l'élément [0] de la liste.
Il semble qu'en cas d'égalité, heapq se base sur l'élément [1] de la liste pour départager les deux cas.
Un message d'erreur survient si l'élément [1] ne supporte pas l'opérateur <
Comment faire pour modifier ce comportement par défaut?
(personnellement j'ai rajouté une variable entière inutile, mais ce n'est pas très élégant...)

Merci par avance pour votre attention

[wiztricks]

Salut,

Comment faire pour modifier ce comportement par défaut?
(personnellement j'ai rajouté une variable entière inutile, mais ce n'est pas très élégant...)

Si je comprends bien ce que vous avez fait est proche de la solution recommandée dans la documentation.

- W

[jingenbl]

Salut,



Si je comprends bien ce que vous avez fait est proche de la solution recommandée dans la documentation.

- W

Pas tout à fait... Mais peu importe, je vais lire la solution proposée que je n'avais même pas repérée.
Il faut dire que mes compétences techniques actuelles en Python sont très largement en-dessous du niveau requis pour la comprendre sans difficulté...

Merci de toute façon

[jingenbl]

Je suis tombé "par hasard" sur une solution plus élégante: rajouter un compteur pour sélectionner les tâches avec priorités égales dans leur ordre d'apparition

Merci pour votre aide

[wiztricks]

C'est une des solutions données dans la documentation du module que je vous avais indiqué:

A solution to the first two challenges is to store entries as 3-element list including the priority, an entry count, and the task. The entry count serves as a tie-breaker so that two tasks with the same priority are returned in the order they were added. And since no two entry counts are the same, the tuple comparison will never attempt to directly compare two tasks.

- W