Téléchargé 8 fois
Vote des utilisateurs
1 
0
Détails
Licence : LGPL
Mise en ligne le 9 mai 2025
Plate-formes :
Linux, Mac, Windows
Langue : Français
Référencé dans
Navigation
Traiter des fichiers en thread
Traiter des fichiers en thread
Pour enchainer sur Le QThread de Tyrtamos, cet exemple montre faire traiter des fichiers divers dans des thread.
Le but est de pouvoir sélectionner plusieurs fichiers, chaque fichier sera alors itéré dans un QThread ligne par ligne et chaque ligne traitée par un traitement défini par callback.
Cet exemple est disponible dans les versions PyQt5, PyQt6 et PySide6.
Le but est de pouvoir sélectionner plusieurs fichiers, chaque fichier sera alors itéré dans un QThread ligne par ligne et chaque ligne traitée par un traitement défini par callback.
Cet exemple est disponible dans les versions PyQt5, PyQt6 et PySide6.
Hello,
Ensemble intéressant, voici quelques remarques qui me semblent empêcher l'optimisation (ce qui semble être recherché sur ce sujet).
En résumé, le code est de bonne qualité et bien commenté... Il y a en grande partie le principe SOLID de respecter sauf le O qui est discutable, mais pas gênant car suit une adaptation liée au besoin.
Ensemble intéressant, voici quelques remarques qui me semblent empêcher l'optimisation (ce qui semble être recherché sur ce sujet).
- Ligne 486 "lig" : len(fic.read_text().split("\n"
) - 1. Pour de très gros fichiers, cela peut consommer beaucoup de mémoire et prendre du temps, bloquant potentiellement l'interface utilisateur pendant cette initialisation. Possible de faire ce comptage dans le thread de travail ? - Ligne 530 self.__work.terminate(). Il arrête le thread de manière abrupte, sans lui donner la chance de libérer proprement ses ressources. La méthode stop semble être plus adapté, qu'en penses-tu ?
- Ligne 522 QApplication.processEvents(). Je laisserai la boucle d'événements principale de Qt gérer cela.
En résumé, le code est de bonne qualité et bien commenté... Il y a en grande partie le principe SOLID de respecter sauf le O qui est discutable, mais pas gênant car suit une adaptation liée au besoin.
Envoyé par Sve@r
suis en train de discuter en privé avec papajoker qui n'a pas le même avis à propos de mon dictionnaire "ihm" permettant de transmettre les infos entre les objets
Envoyé par Sve@r
Faisable mais pas en 2mn
Envoyé par fred1599
Ce n'est effectivement pas un changement de "2 minutes" car il faut modifier la communication entre le thread et le widget.
La version a été uploadée
Envoyé par Sve@r
Effectivement le comptage est long. Il y a une énorme tempo entre le moment où le thread est créé et le moment où le fichier commence à être lu
Quelques (autres) remarques
- dommage que le "métier" soit trop imbriqué dans __QtWork, pour moi aucune bonne raison que __QtWork connaisse la nature du travail : ce n'est qu'un widget généraliste.
par exemple :
self.__fic["lig"] pourrait par exemple être envoyé dans le signal sigInfo / "__slotProgress", sigInfo peut envoyer le nombre de lignes du fichier. Voir même sigInfo retourne directement un pourcentage.
self.__fic["nom"] même chose avec __slotStop
- intéressant a faire :
* pouvoir sélectionner plusieurs fichiers .... (Imaginons que j'ai 12 download en parallèle à faire)
* faire une pause lorsque je clic sur stop (sinon le temps de cliquer sur confirmation et c'est déjà fini)
* pourquoi pas ? en option, ajouter le contenu de la ligne au signal "sigInfo" si on ne désire pas utiliser dans certains cas la fonction callback
- dommage que le "métier" soit trop imbriqué dans __QtWork, pour moi aucune bonne raison que __QtWork connaisse la nature du travail : ce n'est qu'un widget généraliste.
par exemple :
self.__fic["lig"] pourrait par exemple être envoyé dans le signal sigInfo / "__slotProgress", sigInfo peut envoyer le nombre de lignes du fichier. Voir même sigInfo retourne directement un pourcentage.
self.__fic["nom"] même chose avec __slotStop
- intéressant a faire :
* pouvoir sélectionner plusieurs fichiers .... (Imaginons que j'ai 12 download en parallèle à faire)
* faire une pause lorsque je clic sur stop (sinon le temps de cliquer sur confirmation et c'est déjà fini)
* pourquoi pas ? en option, ajouter le contenu de la ligne au signal "sigInfo" si on ne désire pas utiliser dans certains cas la fonction callback
Envoyé par sve@r
Alors... pour le processEvents() j'avais trouvé ça chez tyrtamos qui m'a beaucoup appris. C'était ici: https://python.jpvweb.com/python/mes...console_python. Il indique que ça force le rafraichissement en temps réel. Cela ne devrait pas gêner de ne pas le mettre.
Envoyé par Sve@r
Je crois que je vais le remplacer par quit() mais mettre l'instruction en commentaire...
Question : Pourquoi avoir commenté wait() ?
Toujours utiliser wait() après avoir demandé l'arrêt coopératif d'un thread, pour s'assurer qu'il a bien terminé avant de continuer et de détruire les objets dont il pourrait dépendre.
Envoyé par fred1599
Question : Pourquoi avoir commenté wait() ?
Envoyé par fred1599
Toujours utiliser wait() après avoir demandé l'arrêt coopératif d'un thread, pour s'assurer qu'il a bien terminé avant de continuer et de détruire les objets dont il pourrait dépendre.
(uploadé). Envoyé par fred1599
La boucle d'événements de Qt est très efficace. Il est préférable de le supprimer et de ne le réintroduire que si tu observes concrètement un problème de rafraîchissement visuel que seul processEvents() résout. Même dans ce cas, il faut l'utiliser avec parcimonie.
(uploadé) Envoyé par Sve@r
mais je viens d'y penser: puisque wait() est obligatoire, peut-on alors intégrer directement un self.wait() dans la méthode stop()... ?
Par contre je rendrai cette méthode stop plus robuste,
| Code : | Sélectionner tout |
1 2 3 |
if QThread.currentThread() != self:
self.wait() |
Envoyé par fred1599
Par contre je rendrai cette méthode stop plus robuste,
De nouveau => uploadé
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.