CasusNO

Mugen a écrit : ↑mar. juin 30, 2026 7:10 pm Après, pour vraiment aller vite, il faudra un autre langage que le python.

Ouais, mais après c'est plus mon métier. Moi, chuis un calculeux, pas un pisseux d'code.

Ramentu a écrit : ↑mar. juin 30, 2026 7:10 pm Au passage, si tu n'as jamais plus d'1 million de lignes, Excel fait le boulot en - de 30 secondes (je n'ai pas chronométré précisément, test sur les mêmes tables que celles utilisées pour tester le script))

Rien que de lire ça j'ai des boutons. La plupart du code que j'ai pondu dans ma vie c'était pour ne pas utiliser les macros XL qu'avaient chiétapoté des collègues ; avec Scilab à l'époque... Ça avait donné des trucs comme ça :
https://commons.wikimedia.org/wiki/File ... uselang=fr

(*:Il ne faut que 4 centièmes de seconde à Python pour fusionner les 2 listes. Mais revoyons le tri au ralenti ... )

Paix à son âme.

cdang a écrit : ↑mar. juin 30, 2026 11:28 pm

Ramentu a écrit : ↑mar. juin 30, 2026 7:10 pm Au passage, si tu n'as jamais plus d'1 million de lignes, Excel fait le boulot en - de 30 secondes (je n'ai pas chronométré précisément, test sur les mêmes tables que celles utilisées pour tester le script))

Rien que de lire ça j'ai des boutons. La plupart du code que j'ai pondu dans ma vie c'était pour ne pas utiliser les macros XL qu'avaient pondu des collègues ; avec Scilab à l'époque... Ça avait donné des trucs comme ça :
https://commons.wikimedia.org/wiki/File ... uselang=fr

Justement, zéro macro, une formule standard dans une colonne, et c'est plié
Mais j'utilise Excel (sans macro !) au quotidien, donc "marteau, clou ... "
Et je partage ton aversion pour les macros Excel utilisée à tort et à travers... - c'est pour les éviter que je me suis formé au Python

note : suivant les données, tu voudras sans doute éviter Excel en raison des risques de pertes de précision sur les valeurs réelles passé un certain nombres de décimales. Avec Python au moins, tu contrôles.
J'ai juste testé sous Excel par curiosité pour voir les performances

cdang a écrit : ↑mar. juin 30, 2026 11:28 pm Paix à son âme.

Yes.

Bon, en tout cas ça a marché, merci beaucoup les coupains. 1,21 secondes.

Il me reste une étape itérative (qui prend 26 sec), mais c'est sur une structure de données très liée à mon métier alors je préfère ne pas partager (pas parce que c'est confidentiel, mais pour pas qu'on me retrouve trop facilement ^^)...

J'ai un objet généré par un logiciel métier, on peut utiliser objet.nodes[j] mais si je fais objet.nodes[:], ça me donne un « TypeError: 'slice' object cannot be interpreted as an integer » ; et objet.nodes[0, 1] donne « TypeError: 'tuple' object cannot be interpreted as an integer ».

J'ai essayé la fonction iter() pour faire un itérateur, mais ça semble une impasse. Bon, c'est pas trop grave.

cdang a écrit : ↑mer. juil. 01, 2026 11:32 am J'ai un objet généré par un logiciel métier, on peut utiliser objet.nodes[j] mais si je fais objet.nodes[:], ça me donne un « TypeError: 'slice' object cannot be interpreted as an integer » ; et objet.nodes[0, 1] donne « TypeError: 'tuple' object cannot be interpreted as an integer ».

Ton objet viens probablement d'un environnement non-Python (une API externe ou qqch comme ça), et la méthode getitem de objet.nodes ne gère pas les fonctionnalités "avancées" de Python en terme de "d'indice de tableau" : ni slice, ni tuple, etc.

Il n'y a pas grand chose que tu puisses faire à mon avis, à part parcourir le tableau "à l'ancienne". Quelqu'un de plus pointu que moi en Python te donnera peut-être une astuce, mais là rien ne me vient.

EDIT : en fait, il faudrait savoir quel est le type de la variable objet.nodes pour savoir ce que tu as le droit de faire dessus. C'est ça le problème avec les langages sans typage explicite, comme Python, c'est tellement transparent que parfois on ne sait même pas sur quel type de variable on travaille.

@Nolendur : type() me donne une classe spécifique à l'API.

Mébon, ça va, le traitement total me prend 30 sec (contre 40 minutes lors de mes pires essais ^^), c'est supportable.

Merci de t'y être intéressé.

cdang a écrit : ↑mer. juil. 01, 2026 1:19 pm @Nolendur : type() me donne une classe spécifique à l'API.

On peut imaginer qu'il y a une surcouche Python dans ton outil métier qui fait le travail.
Il y a quelques temps, j'avais travaillé sur une interface qui permettait d'interfacer une librairie écrite en C++ avec un logiciel en java, et le développeur java ne voyait que des classes java.

@Nolendur j'ai un souvenir de mon premier boulot, des tests en Visual Basic 5. Une variable pouvait commencer sa vie comme un tableau d'octets en hexadécimal, puis continuer comme une string avant de devenir un entier. Bizarrement, ça marchait pas toujours bien, surtout que VB avait des bugs...

Un réparateur informatique raconte, dans cet article, les effets de la fin du support de Windows 10 par Microsoft sur ses clients et ce qu'il leur propose.

La seule chose qui retient énormément de monde de passer sous linux c'est la compatibilité avec les logiciels, les pilotes graphiques. Et ces deux problèmes ont la même origine à savoir ne pas vouloir développer pour linux. Et l'émulation ne sauvera pas pour autant. Entre les softs qui opèrent au niveau du noyau et ceux qui demandent tout simplement trop de ressources, wine et cie finissent vite à genou.

La solution intermédiaire est de se trouver une version custom de Win11 qui a été éviscérée pour la bonne cause. Mais là on a d'autres problèmes. La confiance que l'on peut mettre dans ces install customs (on se rappelle tous les versions personnalisées d'XP dont un nombre considérable étaient vérolées jusqu'aux yeux) et le fait qu'elles condamnent plus ou moins à ne plus faire de mise à jour et donc pourquoi s'emmerder avec Win11 alors à moins d'avoir une iso custom patchée à installer à chaque fois qu'une MAJ arrive (bonjour l'usine à gaz).


Sinon, underscore a sorti une vidéo intéressante sur ce qu'on peut avoir quand on achète une iptv.

On commence à être 3 dans notre groupe d'amis à être sur Linux.

On est trois sur Fedora en ce moment et ça marche plutôt bien.