Et puis il existe toujours la possibilité de ne livrer que du bytecode (.pyc), sauf erreur de ma part. Certes cela ne limite que sensiblement la retro ingenierie, mais au moins le code source d'origine lui même n'est pas directement accessible
Oui, Python est adapté à une utilisation professionnelle (argumentez)
Non, il n'est pas adapté pour cet usage et un autre langage doit être choisi (argumentez)
Je n'utilise pas Python
Sans avis
Et puis il existe toujours la possibilité de ne livrer que du bytecode (.pyc), sauf erreur de ma part. Certes cela ne limite que sensiblement la retro ingenierie, mais au moins le code source d'origine lui même n'est pas directement accessible
"La connaissance appartient à tout le monde" (Film Antitrust)
Tout le nécessaire pour Python:
*News/Accueil *Cours/tutoriels *FAQ *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels
Nous venons de retrouver hibernatus .
Merci d'utiliser le forum pour les questions techniques.
Tutoriels OpenGL
Je ne répondrai à aucune question en MP
- Si c'est simple tu dis que c'est compliqué et tu le fait
- Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
C'est souvent une erreur pour les débutants Python de croire que c'est un langage interprété : Python fait partis des semi-interprétés, si cela a encore un sens à l'heure actuelle. La lecture du code génère du bytecode (les pyc de deusyss) qui sera exécuter.
Merci d'utiliser le forum pour les questions techniques.
Je suis que étudiant, mais on m'a toujours appris que le Python était un langage interprété et qu'il était compliqué de protéger le code source contrairement au java et C++
Bonjour,
Peux-tu me préciser ce que tu veux dire par protéger ?
- Rendre illisible (obfuscation)
- Compiler (cython)
- Contrat - license
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Avec un langage "compile", on génère aussi un bytecode appelé langage machine.
Mais il est alors impossible de modifier le programme, par petits bouts, directement sur le système de production, avec le premier éditeur pourri qui traîne.
Pour "compiler", il faut disposer d'une (petite) usine pour fabriquer automatiquement le nouveau programme a partir des sources.
C'est la maîtrise et la disponibilité de cette petite usine qui fera la différence cote qualité du code produit: pouvoir corriger un problème avant de le constater en production.
Un programme scripte ouvre la porte a du bon pour le non informaticien et a des risques que devra adresser de façon "ad hoc" le professionnel.
La seule question a se poser devrait être: "quelles sont les activités de mon entreprise (ou de mon service) qui dépendront de mon programme?"
Un programme est, en général, utile s'il permet d’améliorer la productivité de votre service. Productivité est un terme savant qui traduit "plus d’activités" avec moins de "salaries". Dit autrement, si votre programme tombe en panne, il faudrait embaucher pour réaliser "a la main" tout ou partie des taches correspondantes.
Quelles seraient les conséquences d'un bug? Qui pourra le corriger? Est ce que le programme fonctionnera encore après la mise a jour de l'OS ou du SGDB prévue la semaine prochaine?
Voila les questions que devraient se poser les non-informaticiens (et qu'oublient parfois de se poser les professionnels) lorsqu'ils codent pour une entreprise... (et surtout le responsable du service qui sera en rade en cas de pépin).
Les pièges a éviter sont connus: ils sont répertories sous le vocable shadow IT.
Mais nous sommes incapables de ne pas tomber dedans car nous sommes dans une classe de problèmes dits wicked problem.
"Python c'est bien", "C++ c'est beurk"!
Laissez parler vos tripes, ça défoule!
Dans un forum de "pro", c'est plutôt votre intelligence qu'on devrait essayer de solliciter.
Je trouve (et je suis 200% d'accord avec moi-même) que Developpez laisse faire n'importe quoi sur ce coup la.
- W
Initiation à Qt Quick et QML : Partie 1 - Partie 2
En cas de besoin, pensez à la
Mon site et mes tutoriaux sur Developpez.com
Pas de question technique par MP... Les forums sont là pour ça
Personne n'a ete gene par le GIL de python ?????
Peux-tu donner le rapport avec la question du PO ?Personne n'a ete gene par le GIL de python ?????
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Dans toute discussion, vous avez un sujet initial et plein de sous sujets qui s'ouvrent et se ferment en fonction des échanges.
Dans un forum, ces échanges participent a l’intérêt des discussions. Elles se font entre adultes consentants.
Il y a parfois du "hors charte" ou "hors la loi" - et c'est la que la modération doit intervenir -,
"hors sujet"? Expliquez moi comment vous définissez ça sans tomber dans l'arbitraire. Un forum de discussion n'est pas une FAQ.
Que penser d'une question telle que:
Posée par un débutant, on essaiera de lui expliquer les différents contextes dans lequel ces mots ont un sens et pourquoi il n'y a aucune relation entre eux."Python est-il adapté pour un usage professionnel ou doit-il être considéré comme un langage "bas niveau" ?"
Posée par un modérateur - i.e. quelqu'un qui, a priori, a de l’expérience - ça devient de la "provocation", on ne peut répondre qu'en étant "outre"...
Vous ranimez une "guerre de religions" - des gens qui se battent entre eux. Un forum de discussion, c'est quand même fait pour échanger et y apprendre a être un peu moins bête.
Relisez le réponses.
Je ne suis pas le seul a m’étonner d'un tel sujet de discussion.
Quel genre de "club de développeurs et IT Pro" qu'est Developpez souhaite devenir: n'importe quoi pourvu qu'il y ait de l'audience?
- W
Bonjour,
Je viens de relire tous les messages de ce fil, et je trouve beaucoup de témoignages intéressants qui justifient, à mon avis, la question posée.
Mais vous devriez clore ce fil: il n'apporte plus rien.
Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
Mes recettes python: http://www.jpvweb.com
@wiztricks
Je ne souhaite pas redire tout ce que j'ai déjà dit, par contre je te serais reconnaissant d'avoir une attitude aussi pro que celle que tu defends et de ne pas polluer volontairement les topics qui ne sont pas à ton goût.
En ce qui concerne celui-ci, même s'il est loin d'être le plus populaire de dvp il a permis de débattre sur une question qu'un programmeur est en droit de se poser.
Mais si effectivement il n'est plus que l'objet d'attaques personnelles je vais prévoir sa fermeture dans les heures à venir.
Bonne continuation à tous.
Initiation à Qt Quick et QML : Partie 1 - Partie 2
En cas de besoin, pensez à la
Mon site et mes tutoriaux sur Developpez.com
Pas de question technique par MP... Les forums sont là pour ça
Que cela ne vous apporte plus rien est votre opinion.
Vous pouvez vous désabonner de la discussion (ou pas).
C'est votre choix: il se respecte.
D'autres ont peut être encore envie de dire ce qu'ils pensent sur le sujet et ses sous/sujets. Leur choix n'est pas moins respectable que le votre! Tant que leur échanges restent dans le cadre de la "charte", je ne vois pas pourquoi "clore ce fil".
- W
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 !
Salut,
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.
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!Conclusion : Python n'est pas lent, c'est les développeur qui ne sont pas forcément aussi bon qu'ils le croient !
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:
- "cycle court": ça doit pouvoir changer vite pour répondre au besoin de l'utilisateur.
- "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
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...
Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
Mes recettes python: http://www.jpvweb.com
Je reviens juste sur ça :
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.
À part ma remarque précédente je suis globalement d’accord avec ton message.Envoyé par http://cython.org/
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.
Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit... (Niels Bohr)
Mes recettes python: http://www.jpvweb.com
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager