GuieA_7 a écrit 689 commentaires

Y a-t-il des trucs pour "traduire" une interface tkinter en GTK ou Qt?

Je doute, c'est vraiment des façons de faire différentes (conseil: bien séparer la logique purement métier de l'interface graphique, pour n'avoir à réécrire "que" l'interface en cas de changement, ou pour gérer plusieurs toolkits).

Sur Debian et Ubuntu (désolé je ne suis pas sous Mint, mais c'est un dérivé) tkinter n'est pas installé de base (même si ça fait partie de la bibliothèque standard Python), j'imagine pour avoir Python sur des installations sans interface graphique propres. Mint l'installe vraiment de base (ça m'étonne car il ne doit pas y avoir beaucoup de logiciels l'utilisant, contrairement aux bindings GTK et Qt) ?

J'ai testé et j'ai effectivement du installer via Synaptic sur ma 18.04 le paquet "python3-tk" qui n'avait jamais été installé depuis 2 ans, afin que import tkinter fonctionne.

ce langage a eu une hype immédiate

Je ne sais pas ce que tu appelle "immédiate", mais j'avais écrit un journal sur la version 0.7 en 2013 ; le langage était en développement depuis des années, et a encore mis des années à atteindre la 1.0. Justement parce que ses créateurs se sont concentrés à faire un bon langage, pas juste un langage jetable mais avec plein de trucs dans la bibliothèque standard (donc pas dans l'optique "vite vite utilisez notre langage pour faire votre web app"). Il a mis longtemps à être utilisé en production par des grosses entreprises ; je ne vois pas ce côté "hype immédiate" dont tu parles (qu'à pu avoir nodeJS par exemple).

sans même avoir à le prouver, sans applications

Servo, moteur de rendu HTML moderne (multi-thread, GPU etc…) écrit en Rust a justement été développé en parallèle, les problèmes trouvés servant de retour pour améliorer le langage. C'est une application grosse et complexe, qui prouve sûrement bien plus que le langage est utilisable/efficace que développer 300 bots IRC triviaux. Je ne pense pas que beaucoup de langages aient depuis le début un aussi belle preuve en fait—je pense au C avec Unix, mais il doit quand même y en avoir d'autres.

Impressionnant pour le travail de quasiment une seule personne. Il faudra que je teste ça.

Je crois qu'il faut un peu démystifié cette image de complexité du Rust.

Du coup tu n'a pas démystifié sa complexité ; tu as expliqué qu'elle se justifiait à moyen et long termes. Ce avec quoi je suis tout à fait d'accord (c'était l'essence même de mon commentaire précédant).

Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable

J'avoue que quand j'ai commencé à m'intéresser à Rust il y a pas mal d'années, le fait que Mozilla ait abandonné pas mal de technos me faisait assez peur. J'ai l'impression qu'aujourd'hui le projet est nettement plus porté pas la communauté, ce qui est une bonne chose.

J'imagine que pour des programmes relativement petits comme ceux présentés, même si Rust va rendre l'écriture plus difficile, cela reste de bons terrains de jeux pour essayer d'écrire une implémentation (quasi) optimale (un peu comme on s'amuserait à coder la partie critique d'un code en ASM).

C'est cocasse de dire aux gens de ne pas prendre la mouche, tout en la prenant toi-même. Si tu sors tes idées cash, ne te plaints pas qu'on te réponde cash.

Je serai ravi de lire un journal où tu viens présenter un de tes projets libres en Rust. En revanche lire tes commentaires anti-Python (alors que ça fait longtemps que tu en as fait le tour) me parait nettement moins réjouissant.

Le seul truc écœurant ici c'est ton commentaire. Venir cracher à la gueule de quelqu'un alors que tu n'as ni pris pris 5 minutes pour comprendre à quoi ça pourrait servir (tu n'as jamais entendu parlé de Blender j'imagine), ni pensé que commencer par poser la question serait intelligent…

Ah mais je suis entièrement d'accord.

Personnellement je ne vais pas dire aux gens que leur projet me semble inutile car il y en déjà plein d'autres qui ont l'air de faire la même chose ; je passe juste mon chemin. C'est mon approche, mais peut-être qu'au final elle n'est pas si bienveillante que ça, je ne sais pas (l'enfer est pavé de bonnes intentions, toussa). Peut-être qu'aller interroger les créateurs sur l'utilité de leur projet serait mieux ; ils pourraient alors expliquer ce qu'il apporte selon eux, ou bien expliquer qu'il est fait juste à titre éducatif, etc… Je n'ai pas la réponse.

Moi aussi, j'adore faire mon propre pain. Sans pour autant prétendre rivaliser avec mon (excellent) boulanger de quartier ;)

Si tu te lançais dans la 5ème boulangerie de ta rue, j'imagine que des gens viendraient te demander pourquoi tu fais ça ; d'autres t'ignoreraient. Quelle est la meilleure approche, je ne sais pas.

Ou dis autrement pourquoi est-ce que le fait que ça ne soit pas utile à une ou plusieurs personnes ici devrait remettre en cause ce projet/code/partage ?

Je n'ai personnellement rien remis en cause (cf la 2ème partie de mon commentaire).

Ah, et sur quel critère on se base pour dire que c'est utile ou pas ?

Je ne sais pas ; d'ailleurs je n'ai rien dit de l'utilité de quoi que ce soit, j'ai parlé de "penser". La seconde partie de mon message étant assez claire sur le fait que, bien souvent, garder son avis pour soi est une bonne chose…

Imaginez le monde avec 1 seul fromage, 1 seul vin, 1 seule biere, 1 seule recette de cuisine […]

Ça c'est parce que tu fais un procès d'intention. Tu peux penser qu'une 2ème distribution Linux c'est utile, mais qu'une 2563254ème ne l'est peut être pas autant.

Après j'évite d'aller dire aux gens comment ils auraient du utiliser leur temps libre, mais c'est un autre problème.

… sur le fait que tu doives utiliser un if sur un range (qu'on utilise 99% du temps avec un for).

Avec quelques print dans ton code tu pourrais voir ce qui se passe et trouver tes bugs seul (ce qui est 90% du travail d'un codeur haha).

Bonne chance !

Rust notamment où l'accès direct hors du tableau est possible et génère une belle erreur de segmentation à l'ancienne.

Je crois que c'est plutôt un panic() (le programme quitte de lui-même) plutôt qu'une erreur de segmentation (l'OS tue éventuellement le programme plus tard, quand il détecte des accès mémoires foireux).

On doit quand même pouvoir éviter les vérifications de bornes dans un bloc unsafe (et donc avec cette fois-ci des erreurs de segmentation possibles).

Le logiciel libre c'est politique (sinon, on parlerait d'Open Source)

Pour moi tout est politique, donc autant l'Open Source que le logiciel libre sont politique. Mais oui, l'Open Source est bien plus soluble dans la politique la plus répandue actuellement (le code propriétaire, les services fermés etc…) que le libre. Pour caricaturer, l'Open Source est plus conservateur, et le libre plus progressiste.

[je suis le développeur principal de CremeCRM]

Bonsoir,

Il s’avère que Django a une particularité. Il optimise les fichiers statiques (JS, CSS, HTML, images?) avec un outil écrit en java. Il faut java pour faire tourner une application Django avec de bonne performances.

Cette dépendance n'est pas intrinsèque à Django, mais à CremeCRM. Pour info, nous utilisions une app externe 'mediagenerator' bien avant que Django ait sa gestion actuelle des assets, mais comme sont développement a été stoppée (elle n'est plus compatible depuis longtemps avec les versions récentes de Django) j'ai intégré cette app à notre code, j'ai enlevé la plupart des trucs inutiles pour nous, et porté vers les versions récentes de Django puis Python 3.

Il est tout à fait possible de se passer de Java avec la bonne configuration, mais le JS et le CSS ne sont alors plus minifiés.

Et oui les images subissent un traitement: les assets finaux sont renommés et contiennent un hash dans leur nom (le nom change donc si ont modifie l'image), ce qui permet de dire au navigateur de garder les images en cache aussi longtemps que possible.

Quand j'aurai le temps (spoileur: pas une priorité du tout) je regarderai si les minifieurs JS/CSS écrits en Python donnent de bons résultats histoire de pouvoir enlever Java des dépendances de base.

Il s’avère que Django a une deuxième particularité. Il dépend de Pillow, une bibliothèque logicielle de manipulation d’images. Et Pillow doit se compiler sur la machine lors de son installation.

Il s'agit là encore d'une dépendance de Creme, pas de Django. On s'en sert de manière très légère certes, mais si on s'en sert (cherche des from PIL).

J'espère que CremeCRM vous satisfera (même si effectivement on ne conseille pas spécialement SQLite pour autre chose que le développement, voire une utilisation locale mono-utilisateur).

Le module socket de la bibliothèque standard de Python permet l'utilisation bas niveau des sockets réseau de ton OS (c'est globalement la même chose que ce qu'il y a dans la lib standard du C). Ça te permettrait dans l'absolu, et avec beaucoup de temps, d'implémenter tous les protocoles dont tu as besoin. Mais ce n'est probablement pas ce que tu veux.

Si tu veux juste pouvoir télécharger des fichiers en 3 lignes de code, c'est ailleurs qu'il faut regarder (en gros des gens qui ont déjà fait le travail décrit ci-dessus). Pour HTTP, tu as dans les modules standard de python urllib.request, mais la très bonne bibliothèque externe requests lui est nettement supérieure. Si tu veux une seule bibliothèque qui s'occupe de tout un tas de protocoles, peut-être que pycurl te conviendra plus.

Je dirais que ce que tu décris est un didacticiel/tutoriel ; le souci c'est qu'en cherchant ça dans un moteur de recherche tu tombes surtout sur des didacticiels de programmation, et pas des bibliothèques permettant d'en coder (en admettant que ça existe).

C'est rarement utile, mais ça arrive que la sémantique des arguments change avec leur nombre et ordre. Par exemple la classique fonction range() ne prend pas d'arguments par mot-clé ; ça va pouvoir être formalisé plus proprement dans sa signature avec Python 3.8.

C'est pratique aussi pour les IDE qui extraient un fichier .py représentant l'interface d'un module écrit en C dans lequel les fonctions utilisent uniquement l'ordre des arguments.

de quel(s) support(s) disposes-tu ?

J'allais poser cette question aussi. Ainsi que "Faut que ça soit libre ?" & "Quel budget ?".

Avec reportlab c'est la sanction immédiate, en Go l'erreur est pardonnée.

En l'occurrence c'est plus un biais de confirmation ici.

Bien sûr que Go est plus performant (code natif, typage statique, parallélisme…), mais dans ce cas :

• soit c'est une limite de conception (le PDF est entièrement en RAM) et le code en Go explosera lui aussi, mais plus tard (au sens 'PDF avec plus de pages') ; "l'erreur est pardonnée" n'est vrai que parce que la limite, plus lointaine, te suffit (tant mieux).
• soit c'est une différence de conception (ex: en Python le PDF est entièrement en RAM, en Go il est écrit au fur et à mesure dans un fichier/socket), et dans ce cas comparer les langages est injuste (rien n'empêche—dans l'absolu—de faire la même chose en Python).

D'un autre côté il faut quand même vérifier, à un moment donné, que la contrainte arbitraire 160×205px est respectée  ; si on met une PNG de la taille qu'on veut on a une cartouche avec la capacité qu'on veut.
Après j'imagine qu'il y a sûrement une bonne raison (au moins à la base) pour avoir opté pour cette technique (genre ne faire qu'une seule vérification et pas deux).

Tu t'es déjà fait jeter par terre par des flics pour un splif ?

Plot twist: le flic c'était Zenitram.

Ok merci d'avoir précisé ta pensée et d'avoir regardé pour Gimp.
Pour Blender en revanche je pense que c'est bien embarqué comme tu le décris.