Mais je crois pas qu'il y a une partie vérification intégrée

Ah autant pour moi, j'ai recherché un peu mais j'ai rien trouvé
Merci pour ta réponse !

C'est mon PC qui a un problème ou les programmes fait en python sont vraiment super lent ? Ça me rend fou le temps que ça prend d'afficher un simple "--help" pour un programme console, il y a pas moyen d'avoir un système de cache ou je sais pas quoi pour les programmes qu'on lance souvent ?

Ca peut être une question de hardware, d'OS, de logiciels, d'installation de python etc..
Sous ubuntu je lance très souvent des codes python et j'ai jamais aucun problème de ce genre peu importe le hardware.
Sous windows j'ai eu des soucis à une époque mais vu que j'utilise pas la console sous windows je peux pas te dire.

Sur certains programmes python (à peu près tous ce que j'ai vu) les "imports" sont situés avant la lecture d'arguments. Les imports vont lire des choses sur le disque. Si t'as un HDD lent et que les logiciels que tu lances font des imports lourds, ça m'étonnerait pas que tu ais cette lenteur. Il y a des imports comme des gros frameworks qui sont lents.
Il y a plusieurs systèmes de cache pour gérer ce genre de chose. Il y a des caches automatiques à plusieurs niveaux qui font que si tu lances systématiquement la même chose, tu devrais avoir des réponses plus rapides (cache de la RAM, cache du HDD etc.. je suis pas un expert). Pour ubuntu il y a éventuellement des logiciels que j'ai jamais eu besoin d'installer : https://doc.ubuntu-fr.org/preload

Si t'as pas de RAM, pas de cache HDD, pas de SSD, et pas un processeur très rapide, la lenteur est normale

Ryzen 1700 / 16 Go DDR4 3200 Mhz / SSD / Windows 10. Je pense que ça devrait être suffisant.

Et les programmes dont je parle je pense pas qu'ils soient si gros que ça, c'est genre youtube-dl, c'est juste pour télécharger des vidéos. Mais j'ai bien une bonne seconde avant que le programme se lance. C'est frustrant quand tu te trompes de paramètre, d'avoir un temps d'attente avant de voir le message d'erreur.

Python est pas un langage rapide mais ça devrait pas se remarquer beaucoup non plus
Si tu connais pas, fais des timeit sur ton windows et compare sur un ubuntu par exemple, tu peux le faire assez rapidement via une clé bootable stv (voir VM)

Ca vient de youtube-dl je pense qui importe une tonnes de trucs.

$ cat bla.py 
print ('hello world')
$ time python3 bla.py 
hello world

real    0m0.027s
user    0m0.012s
sys     0m0.015s
$ time python3 color_grid.py # un code interne qui a un peu de dependances
Traceback (most recent call last):
  File "color_grid.py", line 75, in <module>
    main()
  File "color_grid.py", line 14, in main
    bridges = Bridges(int(args[0]), args[1], args[2])
IndexError: list index out of range

real    0m0.312s
user    0m0.291s
sys     0m0.020s
$ time youtube-dl 
Usage: youtube-dl [OPTIONS] URL [URL...]

youtube-dl: error: You must provide at least one URL.
Type youtube-dl --help to see a list of all options.

real    0m0.557s
user    0m0.506s
sys     0m0.048s

Clairement, ce qu'il se passe est que ca prends du temps de charger les bibliotheques. C'est un probleme assez classique en python, il y a assez peu de cache qui peut aider ici de facon general.

Quand l'interpreteur charge, il doit faire deux chose,
1) il doit charger les modules. Et ca prends le temps de parser les fichiers. Potentiellement, ca pourrait etre cache un peu par l'interpreteur. Mias il faudra au minimum que l'interpreteur lisent les fichiers pour calculer un hascode pour verifier si le cache est utilisable. Donc on pourrait retirer le parsing, mais la lecture est difficile a eviter (se reposer sur les date de modification est probablement une mauvaise idee.) Voir meme completement retirer si tu compile ton python. (il y a des outils pour ca, pas sur qu'ils maintiennent aussi bien que cpython).

2) il execute le script d'initialization des modules qui sont charges. Et ca c'est completement impossible a eviter sans reecrire les modules et les applications.

Potentiellement, ca pourrait etre cache un peu par l'interpreteur. Mias il faudra au minimum que l'interpreteur lisent les fichiers pour calculer un hascode pour verifier si le cache est utilisable.

Ça me dérangerait pas de devoir manuellement mettre à jour le cache quand les fichiers sont modifiés. Donc 0 vérifications ça m'irait très bien. Mais bon j'ai comme l'impression qu'il y a pas vraiment de solution toute faite et je sais pas si j'ai envie de passer trop de temps dessus.

Note qu'avoir a maintenir un cache manuellement est une source d'erreur potentielle monstrueuse. Et c'est une des raisons pour laquel les gens preferent les langages interprete aux langages compile. Fondamentallement un programme compile est un cache (in spirit).

J'ai jamais tenté mais si t'as un gros besoin, tu peux peut-être tenter de fonctionner en mode "service".
Genre tu fais un while true (avec sleep) après les imports sur un script qui "attend", et dès que tu lances un signal ce script "service" fait un exec du script que tu modifies.
Enfin si l'objectif c'est de pas faire les gros imports à chaque fois j'imagine qu'il y a des solutions.

c'est rigolo c'est truc la. J'avais ecrit une application qui marchait comme ca. L'application chargait un jeu de donne assez gros quand elle demarrait. Quelques Go en memoire et quelques index manuel. Et pour analyser le jeu de donne, tu recevait le nom d'une bibliotheque dynamique, tu fork, le pere attends la prochaine lib dynamique, le fils charge la lib dynamique et execute une fonction particuliere dedans.

Ca me permettait de tester dynamiquement differente implementation de mes algo sans avoir a recharger le jeu de donne entier a chaque fois.

C'etait rigolo.

Bah ouais, je suis sûr que ça peut résoudre certains problèmes mais vu que ça ressemble à un trick un peu chelou de programmation c'est pas très utilisé x)
En terme de programmation dynamique il y a tout ce qu'il faut en Python. Je fais souvent des eval() sur des données de config. Du coup dans ma config je peux dire à mon script d'importer mes fonctions en mettant le nom de la fonction, sans faire 50 if en fonction de la chaine de caractère.
Je suis sûr qu'il y a 5000 failles possibles mais le code est ultra élégant et c'est ça qui compte pour mes usages.

Après c'est quand même bizarre qu'on puisse pas gérer les imports comme on veut, avec un système de cache en RAM ou autre. Enfin vu que python est suffisament flexible, si on a besoin de lancer 500.000x un script, on met une boucle dans le script après les imports normalement. Et sinon si on a besoin de programmer plus efficacement en modifiant "online" un script, avec spyder ça se fait très bien.
Je fais toujours ça moi, je lance mes imports et ensuite j'exécute des bouts de code à la volée. Ca me permet de tester rapidement 50 codes.

Un des trucs qui me manquait en python mais qui va arriver apparemment c'est le partage de données entre processus. Ca c'est un truc souvent bloqué pour des raisons de sécurité (mon dieu un programme accède aux données d'un autre!), mais ça rendrait certaines choses tellement plus simples si c'était fait efficacement.

up

Un des trucs qui me manquait en python mais qui va arriver apparemment c'est le partage de données entre processus. Ca c'est un truc souvent bloqué pour des raisons de sécurité (mon dieu un programme accède aux données d'un autre!), mais ça rendrait certaines choses tellement plus simples si c'était fait efficacement.

Tu ne peux pas wrapper un appel a shm_open et vivre dans un tableau?

ça sert à quoi printf à la place de print ?

En C, il n'y a pas print; il n'y a que printf. (Evidement, il y a write(2)).

Dans d'autres langages qui ont printf et print, en general printf forunit plus de fonctionnalite pour formatter la sortie.

Bonne année

Quand on y pense, les microservices c'est le principe de la POO adapté au web non ?

j'ai envie de te dire oui. Mais fondamentallement, c'est de la decomposition. La programmation objet c'est juste un format de decomposition particulier.

Tu peux aussi dire que les microservices sont le pinacle (actuel) d'une architecture N-tiers.