Discussion :

[pavel]

Personne n'a ete gene par le GIL de python ?????

[fred1599]

Personne n'a ete gene par le GIL de python ?????

Peux-tu donner le rapport avec la question du PO ?

[airod]

Cela fait maintenant 10 ans que je pythonne. AU début, personnellement, puis depuis 6 ans professionnellement.

J'ai codé des applications web, des serveurs de traitement de données multi process, des serveurs d'échange multi thread, des applications stand-alone de traitement d'image, plus d'autres utilitaires.

Ce que j'en retire de mon expérience c'est que Python est bel et bien un langage pour un usage professionnel.
En effet, peu de langage peuvent prétendre répondre à autant de domaine d'application divers et variés (application web, système embarqué, calcul scientifiques, sécurité, cryptographie, ...)

Ce que l'on reproche souvent à python est sa lenteur. C'est vrai que de devenir bon développeur python ne s'invente pas (mais comme tout langage). il

J'en tire exemple d'une expérience récente.
Un recruteur m'a fait parvenir un bout de code. Je devais lui coder une fonction qui passait tout les cas test. J'ai fait ce petite exercice et renvoyé ma copie.
Sa réponse à été sans appel :
"Votre code est trop lent, nous continuons le procéssus de recrutement si votre code prend 10 % du temps initial"

Piqué au vif, je retravaille ma copie, et à ce jour malgré mes diverses version, je n'arrive pas à descendre au dessous de 20% de mon temps initial.

Conclusion : Python n'est pas lent, c'est les développeur qui ne sont pas forcément aussi bon qu'ils le croient !

[wiztricks]

Salut,

J'ai codé des applications web, des serveurs de traitement de données multi process, des serveurs d'échange multi thread, des applications stand-alone de traitement d'image, plus d'autres utilitaires.

Ce que j'en retire de mon expérience c'est que Python est bel et bien un langage pour un usage professionnel.

Je chipote peut être sur les mots mais votre témoignage porte sur la "generalite" des applications que l'on peut construire avec Python. Contre-exemple: bash et ksh sont des langages de scripting utilisables par tous. Pas facile de les utiliser aussi largement que Python.

Conclusion : Python n'est pas lent, c'est les développeur qui ne sont pas forcément aussi bon qu'ils le croient !

La vitesse dépendra du choix de l'algo. et des ressources CPU/Memoire que le code pourra utiliser. Python libère le programmeur de la gestion mémoire, - pas facile de faire travailler plusieurs CPU,... - C'est super!
Mais impossible, avec Python, d'avoir prise la dessus comme avec C/C++ ou de l'assembleur.
Ça ne veut pas dire que C/C++ sera meilleur que Python: juste que certains langages seront "plus adaptes" que d'autres dans certains cas.

Dans le cas général, tous ceux qui ont suivi une formation d'informaticien ont du entendre que les langages scriptes étaient plus recommandes pour:

• effectuer l’intégration de composants (écrits dans des langages compiles) - la glue -,
• étendre les fonctionnalités de ces composants sans aller jusqu’à la
  réalisation d'algorithmes complexes,
• développer des prototypes ou des applications en cycle court (RAD),

J.Ousterhout, le créateur de TCL répète ca depuis plus de 25 ans!

YouTube et OpenStack sont de gros projets qui utilisent Python comme "glue" entre différents "composants" (allez voir comment ils sont construits) qui peuvent être écrits dans des langages compiles/systèmes.

Le succès de pas mal d'applications est dans la réussite du mélange scripte/compile car il permet de moduler, d'articuler:

• cycle court: prise en compte rapide de nouvelles exigences "métiers".
• cycle long: les exigences sont bien définies et changeront peu... On peut chiader le truc avec un langage compile.

Ce concept est assez répandu:

• SQL est un langage de scripting qui permet a ses utilisateurs de gérer les informations stockées en base de données via un serveur de base de données qu'on écrira en "compile".
• Python - langage de scripting - permet de modifier l’état d'un interpréteur qui est écrit en C.
• L'assembleur est un langage interprété par un processeur "physique" et permet de changer l’état du système (registes, memoire).

Ces exemples sont oses, le but est d'illustrer:

1. "cycle court": ça doit pouvoir changer vite pour répondre au besoin de l'utilisateur.
2. "cycle long": on sait ce qu'on veut et le résultat (processeur, Python 3.3, PostgreSQL) doivent être fiables et performants.

Le langage interprété faisant la "glue" entre les deux.

Pas facile de trouver le "bon dosage" mais il est clair que si dans une équipe de "dev", tout le monde cause le même langage, il faudra trouver d'autres "marqueurs" pour séparer le "stable, a tester et a coder proprement" du reste.

- W

[tyrtamos]

Bonjour,

Concernant la lenteur ou la rapidité de Python, quelques remarques:

1- en restant dans le cadre d'un code en "pur Python", il est clair qu'on peut toujours travailler l'algorithme pour accélérer l'obtention d'un résultat: diminuer le nombre d'appels, de boucles, de conditions, etc... Dans certains cas, il faut carrément changer d'algorithme (y compris, par exemple, passer d'un test exhaustif à un test statistique), dans d'autres cas, on peut changer le code pour tenir compte de la façon dont Python fonctionne (exemples: "for" est en général plus rapide que "while", l'appel à une variable locale dans une fonction est plus rapide, etc...). A l'extrême, pour les parties critiques, on peut utiliser le désassemblage en bytecodes (module "dis") pour améliorer le code.

2- Python est plutôt rapide quand il passe la main très vite à des fonctions écrites en C.

Exemples:
- on peut faire des applications graphiques en Python (tkinter, PyQt, PyGtk, wxPython, ...) tout à fait convenables parce que toute la partie graphique est écrite en C/C++.
- on peut écrire une fonction en pur Python pour calculer la liste des combinaisons de n objets pris k à k (analyse combinatoire), mais elle n'est pas aussi rapide que la fonction "combinations" du module "itertools" qui est écrite en C.
- on peut "chiader" autant qu'on veut un algorithme de tri rapide (y compris "quicksort" de Hoare), on a peu de chance (j'ai essayé!) de faire mieux que la méthode "sort" qui est écrite en C.

==> On a donc intérêt pour avoir la plus grande rapidité à utiliser tout ce qui est déjà disponible dans les modules fournis ou externes, surtout ceux écrits en C.

3- Si dans un algorithme en pur Python une partie est critique pour la rapidité, on peut essayer de l'accélérer grâce à Cython (http://cython.org/): cette partie sera en fait traduite et compilée en C/C++. Elle sera très accélérée (x10 à x100) si les données qu'on fait traiter ainsi sont des types C, et on pourra utiliser directement toutes les ressources des bibliothèques C/C++. A contrario, on gagnera beaucoup moins de temps voire pas du tout, à vouloir traiter des données de types Python qui n'existent pas en C, parce que le code C devra alors multiplier les appels à l'API Python.

4- A part dans le cas d'un benchmark, il ne faut pas raisonner de la rapidité d'un code dans l'absolu, mais par rapport au problème à résoudre. Ainsi, dans un programme, si l'utilisateur a sa réponse en 0.1 seconde et si ça suffit, le fait de changer pour un langage plus compliqué pour la donner en 0.01 seconde est une perte de temps.


En appliquant ces principes, on arrive à avoir le "meilleur des deux mondes", c'est à dire un développement facile et rapide (grâce à Python), et une rapidité d'exécution satisfaisante (grâce à C/C++). D'ailleurs, après traitement avec cx_freeze et utilisation d'un "installeur" (ex: innosetup sous Windows, paquets rpm ou dev sous Linux), l'utilisateur ne saura même pas que le logiciel qu'il exécute a été écrit en Python...

[grim7reaper]

Je reviens juste sur ça :

cette partie sera en fait traduite et compilée en C/C++.

Le C/C++ ça n’existe pas.
C’est un horrible amalgame bien trop répandu à mon goût.
En l’occurence Cython compile en C, pas en C++ et encore moins en C/C++ qui ne veux rien dire.

This allows the compiler to generate very efficient C code from Cython code.

À part ma remarque précédente je suis globalement d’accord avec ton message.

[tyrtamos]

Le C/C++ ça n’existe pas.
C’est un horrible amalgame bien trop répandu à mon goût.
En l’occurence Cython compile en C, pas en C++ et encore moins en C/C++ qui ne veux rien dire.

Désolé, mais c'est faux: avec cython, on peut demander la compilation en C OU en C++. C'est dans la doc: http://docs.cython.org/src/userguide...CPlusPlus.html.

Et pour l'avoir déjà utilisé, je confirme que ça marche.

[Jiyuu]

Je pense que tyrtamos voulait dire C ou C++ en écrivant C/C++

[moons17]

Python permet de développer des applications crossplateforme window-mac-unix sans trop de problème de compatibilité de librairie et se prête également à un usage de de script d'exploitation.
l'accès à ses bibliothèques ne nécessite pas le développement de dll ou autre mécanisme d’accès comme pour le framework .net qui en limite l'usage et les capacité du vbs par exemple pour le monde windows;
Actuellement je convertis une partie de mes scripts d'audits écris en vbs pour étendre leur capacités au monde mac/unix et transforme un script en particulier en application industrialisé python prenant en compte les problématiques et contrainte de chaque type de plateforme

ce langage est un outil professionnel pour peu que l'utilisateur se conduit comme telle et industrialise son code ( ce qui est rarement le cas au vu des problèmes de mise en production lié à la gestion de l'environnement , des code d'erreur et autre ... auxquelles j'ai été confronté ces 3 derniers années )

nota: python 2.7 est natif sous mac ( fournis avec ) et complètement intégré à l'outil gratuit de développement Xcode

l’intégration de python 3;x ne pose pas de problème non plus

Quelque soit le langage, les performances seront meilleures en évitant de solliciter le SGDB i.e. faire des entrées/sorties disques qui induiront des délais dans les séquences de traitements et qui pourront devenir "goulot d’étranglement".

coté SGBD la bete noire des DBA c'est l’écriture une à une des transaction alors qu'une commande existe pour pousser en masse les données et faire un seul Commit au lieu de x ce qui consomme des ressources ;
sur des SI construit autour d’échange de donnée de masse cela peut-être très critique , le problème c'est que souvent les problèmes de perf lié à ce point s’apparait qu’après la phase de VSR (vérification service regulier ) c'est à dire une fois que le changement à été généralisé alors que la consultation du DBA dans la phase d'analyse de la construction de l'application aurait été necessaire .

un exemple de développement python professionnel qui fonctionne depuis 10ans http://www.eveonline.com/ ( leur client de jeux à 90% et une partie coté serveur)
une chaine de mise en production propre et environnement de test , mass test , lotissation... (client windows, mac , unix ) 350k de compte 50k de connection en moyenne chaque jours ,
c'est à la porté de tous de faire du code , faire une application ça l'est moins et une application industrialisé maintenu correctement encore moins , le challenge est là

[RyzenOC]

Pas de compilation, un typage dynamique, une syntaxe succincte, un debugger intégré, un shell de tests et des stack traces très verbeuses.
Il y a de la doc, de la vrai (souvent dans les autres langages c'est soit rien, soit des gros pavées de texte incompréhensible).
On peut pas codé cradement, il as une syntaxe simple et clair et qui force l'indentation. Difficile de mal codé sans faire exprès. Voila c’est ce que j’aime on indente pour quelque chose en double avantage stucture et lisibilité et peu de sucre syntaxique.
Pas besoin d'installer des EDI de 10Go pour l'utiliser, on télécharge le programme (qui est leger) et un bloc note (notepad++, sublime text...etc) et sa marche.
On peut tous faire (du web, des jeux 3D, du calcule scientifique, du big data...etc) et on peut utiliser des sgbd (Postgres, SQLite...etc).

Le langage évolue (2 version/ans qui apporte des fonctionnalités/optimisation), il ne se meurt pas.
Il est vieux et as de l'expérience (1990)

Au final, on as un langage qui permet de codé n'importe quoi, rapidement, proprement, gratuitement et sur n'importe quels machine (pas besoin d'un I7+SSD avec Visual Studio). Que peut bien demander d'autre une entreprise ?


1 défaut, le passage de python 2 a python3, sa à pas mal fracturer le langage, il existe encore beaucoup de script codé en python 2.7, la bonne nouvelle c'est que les 2 versions peuvent co-exister sur une même machine quand même.

[tyrtamos]

Bonjour,

Juste un petit complément au passage.

Pour coder "pro", il faut coder "solide" et pouvoir le prouver (assurance qualité). Or, en tant que langage interprété, Python laisse passer certains types d'erreurs, tant que la partie du code qui les contient n'a pas été sollicitée. Et donc, s'il y a ce type d'erreur et que les contrôles n'ont pas été assez loin, c'est l'utilisateur qui s'en apercevra, et peut-être longtemps après son acquisition...

Prenons un exemple simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
def toto():
    print(2)
 
def tata():
    print(machin)
 
ok = True
if ok:
    toto()   
else:
    tata()

On voit bien que la variable "machin" n'est pas déclarée, ni en global ni en local. Mais aucune erreur ne sera déclarée en exécution parce que la fonction tata n'est pas sollicitée tant que ok est True. Mais si on met ok=False, il y a bien une erreur.

La conclusion est facile à comprendre: pour coder "pro" il est indispensable d'utiliser un analyseur de code. J'utilise pour ma part "pylint" qui donnerait dans le cas ci-dessus, même avec ok=True, le message:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

E:  5,10: Undefined variable 'machin' (undefined-variable)

Cet analyseur de code donne en plus beaucoup d'autres informations (erreurs, alertes, informations), y compris des recommandations pour s'approcher des bonnes pratiques de codage de Python (pep8).

A noter que certains outils de développement intègrent ce type d'outil.


En plus de cet aspect, je trouve que les outils qui permettent de fabriquer facilement une documentation par extrait des "docstrings" sont très intéressants: pour un informaticien, l'élaboration d'une documentation est le plus souvent un travail nécessaire mais pénible... Or, avec Python, il suffit de commenter suffisamment le code, ce qui est de toute façon nécessaire pour permettre sa reprise par un autre programmeur (autre aspect du codage "pro"...)! pour faire au moins une documentation minimale. Un outil comme pydoc est un minimum, mais il y a mieux ailleurs (sphinx par exemple). Cependant, ça s'ajoute à une documentation utilisateur "pédagogique" sans la remplacer...

[BufferBob]

salut,

j'en rajoute une couche rapidement en disant que pour la partie admin (c'est une profession aussi) les indentations de Python sont une contrainte non-négligeable, un admin faisant souvent bien plus de oneliners que de scripts, ce qui explique sans doute que Perl reste -malgré tout le bien que je peux penser de Python- indétrôné en entreprise
pour autant j'ai déjà vu des admins utiliser Python pour leurs scripts en production, mais ça reste tout de même encore assez rare

[Christophe]

Mon avis de non utilisateur :

Je vais partir sur le dernier commentaire récent de Sazearte

Pas de compilation : c'est à la fois son avantage et son inconvénient - cela dépend de ce que l'on veut, pour du langage scripté c'est ce que l'on recherche, et ça aura l’avantage de fonctionner sur n'importe quelle machine possédant un interpréteur python, d'être modifiable facilement. Pour la vitesse l'interprété c'est pas ce qu'il y a de mieux mais il y a eu une solution évoquée : cython. Cela m'apporte une question, existe t'il des moulinettes pour transformer du code Python en C/C++ ? Probablement.

typage dynamique : Peut être une grosse source de problème, que ne laissera pas passer le langage C par exemple, mais cela apportant la contrainte de devoir déclarer les variables, mais cela est également valable en PHP par exemple. Y a t'il moyen de typer les variables ? ce qui apporterait la souplesse de la non-déclaration si c'est le choix qu'on en fait.

Il y a de la doc, de la vrai : Je confirme, je m'y étais intéressé et la doc officielle fiat au moins 1500 pages. De ce que je m'en rappelle, elle intègre pleins de bibliothèques non natives Python mais couramment utilisées.

1 défaut, le passage de python 2 a python3 : c'est un des points qui me rebuterais à l'utiliser, surtout que cela fait un moment que les 2 branches co-éxistent. Puis en regardant ceci : https://docs.python.org/3/whatsnew/3.0.html on peut voir que ce n'est pas non plus violent et si vous regardez le dernier paragraphe, vous verrez qu'en utilisant le paramètre -3 avec Python 2.6, il y aura des warnings sur les points à problème et qu'un convertisseur est fourni (après il est peut-être pas parfait...).


Et comme l'exemple de tyrtamos, il est facile de reproduire cela avec un langage compilé comme le C, une simple mauvaise utilisation de pointeur dans une partie de code peu utilisée génèrera un segfault, ou pire des données erronées.

Et enfin en ayant parcouru le post, je me suis rendu compte que beaucoup ne savaient pas ce qu'on appelait un langage base niveau et un langage haut niveau.

Et pour répondre à la question "Python est 'il adapté à un usage professionnel ?"
Que demande t'on dans le monde professionnel : être efficace. Python est simple à prendre en main, peut répondre à quasiment toute problématique demandé, onc oui il est adapté, mais de toute façon ce n'est pas un bon outil qui fait un bon ouvrier.

[RyzenOC]

1 défaut, le passage de python 2 a python3 : c'est un des points qui me rebuterais à l'utiliser, surtout que cela fait un moment que les 2 branches co-éxistent. Puis en regardant ceci : https://docs.python.org/3/whatsnew/3.0.html on peut voir que ce n'est pas non plus violent et si vous regardez le dernier paragraphe, vous verrez qu'en utilisant le paramètre -3 avec Python 2.6, il y aura des warnings sur les points à problème et qu'un convertisseur est fourni (après il est peut-être pas parfait...).

Pour du code python sandard oui la conversion peut ne pas etre trop douloureuse.

MAIS qui code en python sans utilisé de bibliothèques ? Pal mal de bibliothèques ont mis du temps (ou ne l'on pas encore fais) pour passer a Python3.
Numpy par exemple à mis du temps avant d'avoir une version complete porté sur python3.
Panda3D par exemple (une bibliotheque pour faire des jeux 3d) n'est pas encore passé en python3, c'est encore au stade béta.

Si je compare à la transition entre PHP5.6 et 7, python sa à été l'enfer. Ubuntu par exemple utilise encore pas mal de script codé en python 2.7, si la migration est facile il l'aurais fait depuis des années.


Pour ma part j'ai jamais aimée les langages comme le C car trop restrictifs. Avec python, je peut mettre n'importe quoi dans des listes par exemples.
Python est très agile, ce qui permet de modifier/adapter un programme rapidement. Tres pratique quand le client sait pas ce qu'il veut (c'est du vécu)