Le mariage de Python et Rust vous intéresse ?
Profiter des modules de Python au sein de Rust, de la sûreté de Rust pour accélérer les traitement de Python, de la possibilité d'intégrer à l'interpréteur des bibliothèques systèmes… ?
Je vous propose dans cette nouvelle note technique, de nombreux exemples et analyses du fonctionnement au travers de ctypes et du C, pour améliorer la performance de Python et étendre Rust.
https://code.nothus.fr/doku.php?id=python:rust_python
(màj possible dans le temps)
# Beurk, écoeurant ....
Posté par totof2000 . Évalué à -8.
A la limite, faire des appels Rust depuis python pourquoi pas, mais le contraire me paraît un peu antinomique avec les objectifs de Rust.
[^] # Re: Beurk, écoeurant ....
Posté par totof2000 . Évalué à -10.
J'aurais bien tenté une comparaison mais la bien-pensance actuelle fait que je préfère m'auto-censurer (terrain glissant).
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . Évalué à 4.
?
[^] # Re: Beurk, écoeurant ....
Posté par Faya . Évalué à 4.
"If you’re thinking about getting in touch saying this is political correctness gone mad, don’t bother."
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . Évalué à 3.
Cf. l'extrait de l'article sur RedHat. NumPy est l'exemple parfait d'un intérêt à avoir autre chose que du pur Python. Rust permet d'avoir un code conforme au C. La transition est vite faite.
La possibilité de le faire ne veut pas dire toujours le faire, ni que ça ait un sens tout le temps.
En ayant la possibilité de renvoyer vers Rust une fonction générée lors de l'exécution, lambda ou autre, ça peut être sympa de profiter dans Rust d'une composition issue des bibliothèques de Python. Tu profites d'un code en Python en façade, avec du Rust derrière.
Autre point, Rust agit avec du C sans difficulté, il suffit de prendre les bonnes précautions.
Peux-tu m'indiquer plus précisément l'antinomie que tu y vois ?
[^] # Re: Beurk, écoeurant ....
Posté par totof2000 . Évalué à 3. Dernière modification le 06 mai 2020 à 14:09.
C'est l'appel de code python par rust qui me gène plus. Quoiqu'en y ayant réfléchi un peu, ça pourrait être utile pour implémenter des trucs du genre système de macros basés sur Python dans le cas d'un soft style Libreoffice, ou ce qu'on fait avec LUA dans des moteurs de jeu, dans NGINX. Mais bon, LUA a pour gros intéret d'être très rapide et très léger. Je ne sais pas ce que vaudrait python à côté.
[^] # Re: Beurk, écoeurant ....
Posté par YetiBarBar . Évalué à 5.
Le cas des extensions python pour un programme écrit dans un autre langage (blender, gimp, …) n'est pas un cas si isolé.
Tu peux avoir une équipe qui s'occupe d'améliorer un programme core où tu veux profiter des avantages du Rust et vouloir exploiter des modules existants ou à développer par des personnes dont la programmation n'est pas le métier (et qui te pondront un Python correcte mais jamais de Rust).
Tu peux aussi avoir une forte dépendance à une librairie exploitable uniquement en Python.
En tout cas, si tu as un soft "avec du vécu", tu ne migres pas en un jour (ni les coders, ni la codebase)
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . Évalué à 3.
Je veux pas dire de bêtise (vraiment, je fais de mémoire), mais finalement LUA c'est un simili-code C qui est compilé en JIT comme ce serait avec GCC. Donc oui, question efficacité pure, ce serait bien mieux que Python (bytecode oblige).
Question lib dispo, Python gagne j'imagine.
Exactement, c'était mon idée !
[^] # Re: Beurk, écoeurant ....
Posté par Thomas Douillard . Évalué à 5.
Euh non, lua n’a pas grand chose à voir avec C, c’est plus de la famille du js (langage à typage dynamique, à prototype).
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . Évalué à 3.
Oups. Toutes mes excuses ! :/ ça m'apprendra à ne pas chercher d'abord.
Pense-bête : https://www.lua.org/history.html
[^] # Re: Beurk, écoeurant ....
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Moi j y vois un intérêt car Python a beaucoup de librairies complexe a redevelopper. Par exemple j utilise sympy (lecture d expression mathématique et simplification voir resolution d equations). Ainsi un logiciel pourrait être développé en Rust faire des opérations complexe efficacement et quand nécessaire utiliser sympy pour comprendre et simplifier une formule.
En fait concrètement cela permet d augmenter la part de Rust. Devellopper un logiciel en Rust et utiliser Python là ou les libs Rust n existent pas au lieu de developper un logiciel en Python et de le couvrir de bout de code Rust pour l optimiser. Comme librairie je pense aussi a expect.
Une dernière remarque, qui, en C n a pas fais un appel a une commande bash…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beurk, écoeurant ....
Posté par GuieA_7 (site web personnel) . Évalué à 1.
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…
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . Évalué à 2.
Pour compléter les exemples sur les logiciels qui s'accompagnent d'accès à ou de langages intégrés, ce serait l'automatisation de LibreOffice grâce à Python :
https://wiki.documentfoundation.org/Macros/Python_Guide/fr/Initialconcepts
(et)
https://wiki.documentfoundation.org/Macros/Python_Design_Guide/fr
… Si quelqu'un a d'ailleurs un retour d'expérience sur UNO, ça m'intéresse !
[^] # Re: Beurk, écoeurant ....
Posté par totof2000 . Évalué à -8.
Faut respirer un peu et prendre l'air …. et regarder à qui tu parles.
Je ne crache à la gueule de personne … C'est juste que python fait partie des langages que j'aime le moins et que Rust fait partie des langages que je préfère, et j'ai parfaitement le droit de penser que ce "mariage" "ecoeurant (même si j'ai volontairement exagéré le propos un peu par provocation). Rien de personnel sur l'auteur du message en tout cas.
Ah parce que tu te crois plus intelligent c'est ça ? Et ta réaction l'est certainement plus …. J'avais pas envie de faire dans le mielleux ni dans le politiquement correct. J'ai sorti mon idée cash, comme ça me venait, et j'ai grossi le trait, comme ça m'arrrive de temps en temps ici. Prendre la mouche pur ça c'est ridicule. Et encore, comme je l'ai dit, il y a plusieurs comparaisons qui me sont venues à l'esprit au sujet de ce "mariage", mais j'ai préféré m'auto-censurer. Faut pas demander si je ne l'avais pas fait …
[^] # Re: Beurk, écoeurant ....
Posté par Anonyme . Évalué à 6.
Ouin ouin on peut plus rien dire.
[^] # Re: Beurk, écoeurant ....
Posté par passant·e . Évalué à -4.
Il doit regretter de ne plus pouvoir lancer des nains, ne plus pouvoir siffler des femmes dans la rue, ne plus pouvoir sortir ses meilleures blagues homophobes en public et pleins d'autres choses qu'il place dans le "politiquement correct" et un manque d'auto-dérision (surtout quand cela ne le concerne pas). Par contre, n'allez pas lui faire des blagues sur les dépressifs, les mecs qui ne sont pas bien dans leur peau et dans leur vie familiale. Ce serait de très mauvais goût.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Beurk, écoeurant ....
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 07 mai 2020 à 14:39.
Et après on critique mon ton direct… J'ose espérer qu'on voit que j'ai un peu plus d'argument qu'un goût personnel "j'aime pas".
Prend alors pas la mouche : tes idées sur la chose sont de la grosse merde, que ce soit sur la forme que sur le fond, dont on a rien à foutre, pour les raisons écrites plus haut.
C'est pas plus "cash" que toi mais avec déjà plus d'arguments, c'est dire le niveau de ce qui est critiqué.
Au final, tu n'aimes pas… Pourquoi alors pas juste passer ton chemin?
C'est lourd (et j'ose espérer que c'est vu comme encore plus lourd que mes réactions argumentées avec un fond) les gens qui viennent dire "la glace au chocolat c'est pas bon" quand tu commandes ta glace au chocolat tranquille sans impacter le moins du monde ceux qui n'aiment pas la glace au chocolat.
PS : tu comptes faire un journal tout aussi vide d'arguments pour dire que tu n'aimes pas?
[^] # Re: Beurk, écoeurant ....
Posté par GuieA_7 (site web personnel) . Évalué à 6.
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.
# Connection python -> C
Posté par nekopep . Évalué à 3.
Intéressant,
Je ferais le parallèle avec un usage que nous avons fait en c++.
Développement d'algos de traitement de signal en python puis intégration de ces derniers dans une IHM QT/C++.
Le gros intéret est l'énorme librairie de calcul python.
On a aussi joué a générer des images avec matplotlib et les afficher ds l'IHM C++ :D
Donc oui ca peut être trés utile!
Dans notre cas, nous avons utilisé cffi et pybind11 qui sont plus sympa et facile d'accés que ctypes!
Je ne sais pas si dans ton cas cela pourrais s'appliquer, mais cela nous a changé la vie!
[^] # Re: Connection python -> C
Posté par JulienG . Évalué à 3.
Merci du retour d'expérience ! Même constat que vous : j'avoue qu'utiliser les lib de Python (notamment pour les hash, pas toujours évident de faire un code vraiment correct), ça me botte bien. Votre projet a l'air pas mal, c'est en usage pro ?
Probablement que oui pour cffi et pybind11. Là c'est une note de travail et de recherche perso que j'ai rendu publique pour ctypes, sans vraiment prétention sinon de dire "c'est possible avec les modules standards de chez Python et de chez Rust". Je vais approfondir le sujet prochainement.
Pour l'instant j'ai une autre idée farfelue : un interpréteur Lua pour Python, via Rust. Parfaitement inutile mais tout à fait sympa. Hum, ça sent le joli casse-tête du long weekend… :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.