On ne peut pas créer un exécutable d'un projet Python.
Ben si pourtant. C'est pas la manière la plus courante de déployer des programmes Python mais ça se fait très bien. Sous Windows, j'utilise pyinstaller qui marche également sous Linux, MacOS, AIX, FreeBSD et Vagrant.
Le déploiement peut péter lors d'un "pip install" parce que pip lui-même
Aujourd'hui, il me semble que ce problème de contrôle du déploiement se résout par un contrôle très figé de tes dépendances. On ne balance pas une mise à jour de ses dépendances en aveugle en production.
Ce problème n'est d'ailleurs pas spécifique à Python, c'est avant tout un problème d'utilisation de dépendances et de contrôle de leur stabilité. Ce problème touche tous les langages qui fournissent facilement des paquets installables, node.js étant bien plus affecté encore que Python. L'absence de vérification de la cohérence des types accentue bien sûr le problème. J'ai espoir que les annotations de type systématiques réduisent une partie de ce problème.
L'écosystème très riche et dynamique de Python permet de démarrer un projet complexes en quelques jours. Mais cela se paie à un moment donné par une exigence de connaissance plus fine sur les dépendances et leurs risques. Comme disent les américains, "un repas gratuit, ça n'existe pas" ("there ain't no free meal").
Certains langages sont très stables, même si leur compilateurs évoluent, même si les librairie évoluent. On peut exécuter un programme écrit il y a plus de 20 ans. Vous vous rendez compte ? (là je pense à Common Lisp)
Ok, il y a eu la transition Python 2 -> Python 3. Mais en dehors de cela, tu as en tête beaucoup de fonctionnalité du langage de Python 3.0 qui ne seraient pas supportées dans Python 3.10 ? Ou de fonctionnalité de Python 1.4 qui ne sont pas supportées par Python 2.7 ? A froid, il n'y a rien qui me vient en tout cas.
La comparaison avec Common Lisp, allons-y: c'est sur que la conception fonctionnelle du langage et des frameworks aident à exclure plein d'erreur qui permettent aux bibliothèques d'évoluer plus sereinement. Mais aussi, on parle d'un langage avec une base d'utilisateurs/développeur très réduite en comparaison de Python. Du coup, c'est sûr que ça évolue moins, et c'est même aussi une des raisons qui font que sa popularité reste faible. Au fait, je fais comment pour faire une interface graphique multi-plateforme moderne en Common Lisp ? En Python, j'utilise PyQt ...
Cela dit, je partage une partie de tes critiques, à savoir que Python tout seul, cela ne suffit pas. Il y a un certain nombre de bonnes pratiques qu'il faut acquérir, en particulier s'entourer d'outils externes pour fiabiliser ton code.
[^] # Re: L'interview de moi-même - mes frustrations
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python — partie 10 — Entretiens. Évalué à 4.
Ben si pourtant. C'est pas la manière la plus courante de déployer des programmes Python mais ça se fait très bien. Sous Windows, j'utilise pyinstaller qui marche également sous Linux, MacOS, AIX, FreeBSD et Vagrant.
Aujourd'hui, il me semble que ce problème de contrôle du déploiement se résout par un contrôle très figé de tes dépendances. On ne balance pas une mise à jour de ses dépendances en aveugle en production.
Ce problème n'est d'ailleurs pas spécifique à Python, c'est avant tout un problème d'utilisation de dépendances et de contrôle de leur stabilité. Ce problème touche tous les langages qui fournissent facilement des paquets installables,
node.jsétant bien plus affecté encore que Python. L'absence de vérification de la cohérence des types accentue bien sûr le problème. J'ai espoir que les annotations de type systématiques réduisent une partie de ce problème.L'écosystème très riche et dynamique de Python permet de démarrer un projet complexes en quelques jours. Mais cela se paie à un moment donné par une exigence de connaissance plus fine sur les dépendances et leurs risques. Comme disent les américains, "un repas gratuit, ça n'existe pas" ("there ain't no free meal").
Ok, il y a eu la transition Python 2 -> Python 3. Mais en dehors de cela, tu as en tête beaucoup de fonctionnalité du langage de Python 3.0 qui ne seraient pas supportées dans Python 3.10 ? Ou de fonctionnalité de Python 1.4 qui ne sont pas supportées par Python 2.7 ? A froid, il n'y a rien qui me vient en tout cas.
La comparaison avec Common Lisp, allons-y: c'est sur que la conception fonctionnelle du langage et des frameworks aident à exclure plein d'erreur qui permettent aux bibliothèques d'évoluer plus sereinement. Mais aussi, on parle d'un langage avec une base d'utilisateurs/développeur très réduite en comparaison de Python. Du coup, c'est sûr que ça évolue moins, et c'est même aussi une des raisons qui font que sa popularité reste faible. Au fait, je fais comment pour faire une interface graphique multi-plateforme moderne en Common Lisp ? En Python, j'utilise PyQt ...
Cela dit, je partage une partie de tes critiques, à savoir que Python tout seul, cela ne suffit pas. Il y a un certain nombre de bonnes pratiques qu'il faut acquérir, en particulier s'entourer d'outils externes pour fiabiliser ton code.