Les projets Open Source ne se soucient généralement pas de Windows, puisque leurs développeurs utilisent Linux car "Window$ pue".

=> à partir de la j'ai arrêté de lire, python a une communauté énorme pour tous les systèmes, même android et surement iOS. Dire que sa communauté de développeur pue c'est une grosse connerie deja. maintenant ça peut cibler les personnes qui développe spécialement le coeur de python, et là ça tient meme plus de connerie, c'est une insulte, car ils font un boulot monstre pour :
1) que l'api soit sans bug (test unitaire, il suffit de voir la rigueur du chef de projet)
2) que l'api soit pour tout le monde le plus facile a utiliser

apres pour le reste :

2) : qu'est ce qu'on entend par API stable ? une API qui évolue pas ? la seule différence a été python2->3 mais python2 est toujours maintenu et python3 corrige beaucoup d'ancienne erreur, a vous de faire le choix.

3) : changez d'interpréteur, apprenez a utiliser l'api C de python, au choix (par exemple).

4) : c'est la force de python, un langage entierement dynamique, cf web2py avec les sessions par exemple. vous pouvez coder correctement et vous n'aurez pas de problème.

5) : quel être stupide dénué de sens ferait ça de cette manière ? c'est tout l'intéret des décorateurs, pouvoir faire fonction1 = fonction_decorateur(fonction1), ou renommer une fonction. Encore une fois c'est un langage dynamique et elle n'est détruite que dans le contexte.

6) : vous aimez ou vous n'aimez pas, personnellement je ne l'ai jamais même remarqué

7) : ah bon ? moi c'est tout l'inverse, je peux faire un type bloc qui défini un bloc et foutre dedans, tout ce qui est dans le bloc est indenté, y compris les blocs compris.
Python est en plus très simple, peu verbeux, donc peu de cas a gérer. Et au passage la création du python est faite pour simplifier la lecture par exemple : http://en.wikipedia.org/wiki/Python_%2 [...] g_language%29 .

8) avis subjectif, """ """ permet de mettre en valeur sans avoir de problème, c'est lisible, __machin__ c'est la signature d'une fonction native, ça permet d'indiquer simplement(encore) que c'est une fonction associé a qque chose au langage.

9) Pourquoi y a-t-il ":" dans la syntaxe si il y a quasi-toujours une nouvelle ligne derrière ? Bah parce qu'il peut y avoir une instruction derrière et que ça permet de mettre en valeur le debut du bloc tres simplement.
Un dictionnaire est un objet, un module est un objet, tout est objet.
Les typages sont encore une fois pour que ce soit lisible, et dynamique (tout peut etre objet, tout peut devenir tout).
Il n'y a pas la meme notion d'héritage que dans les autres langages, c'est plutot une notion d'interface, un objet doit savoir faire ce qu'on lui demande c'est tout.
Pour le reste, je ne connais pas.

10) Soit, peut etre, si vous le dîtes, mais la mémoire est vidée a la fin du programme, il n'y a pas de fuite du moment que l'on code bien et je suis bien content de ne pas avoir a gérer la mémoire pour un code simple.

11) Dans ce cas pas la peine d'utiliser ou de discuter sur le python, soit on voit ses avantages, soit on prend un langage qui en a d'autre, c'est subjectif et complètement personnel !

Le problème avec ce genre de liste c'est que tu pourrais quasiment faire la même chose avec tous les langages. Pointer du doigt des défauts d'un langage je vois pas où ça amène qui que ce soit surtout que parfois c'est plus du domaine de l'histoire de gout qu'autre chose " la syntaxe de python est difficile à comprendre " (ça dépend pour qui), d'autres vont vomir sur l'indentation etc...

Puis après il y a des trucs qui sont plus du domaine de la mauvaise foi genre

Citation

Le Verrou Global de l'Interpréteur est une barrière importante à la concurrence et au parallélisme.

On parle de l’interpréteur pas du langage en lui même, même moi graphiste de formation, programmeur du dimanche, je sais très bien que tu peux utiliser IronPython ou Jython. Puis il existe des module pour le multiprocessing.

Personne a la prétention de dire que Python est parfait, que python est meilleur que X ou Y. Moi je m'en sers pour faire du shell voire des sites, ou pour des apps plus petites.

Honnêtement ce genre de listing ne mène jamais à rien...Si plusieurs langages existent c'est pas pour faire joli ou faire des sous sections sur le SdZ, c'est parce qu'ils ont tous leurs avantages / défauts / utilité. A chacun d'aller voir de lui même.

J'ai lu brièvement ces différents points et je pense qu'il n'a pas tord sur certains point dont un que j'ai moi même fait la remarque qui est celui de déclaration de type (comme int en C/C++).

Après, le reste reste très subjectifs et ne sont pas des gros défaut (limite on ne les remarques pas trop).

Tout langage a des défaut mais des qualités. Si un langage n'aurait aucun défaut, il serait le langage parfait or cela n'existe pas .

Citation : FirstZero

J'ai lu brièvement ces différents points et je pense qu'il n'a pas tord sur certains point dont un que j'ai moi même fait la remarque qui est celui de déclaration de type (comme int en C/C++).

Wut ?

C'est simplement que le langage a un typage dynamique, ce qui permet de lever plusieurs barrières et gagner beaucoup de temps dans pas mal de cas. Je ne suis pas là pour dire "le typage dynamique c'est mieux dans l'absolu", puisque j'aime autant Haskell (avec son typage autistique) que Python, seulement les deux langages correspondent simplement à des façons de penser, et de travailler, très distinctes.

Je n'ai pas le temps de réagir à la liste point par point pour le moment. Je le ferai probablement plus tard.

@nohar : il n'y a même pas besoin de réagir point par point, l'auteur de cette liste exprime son avis et son ressenti sur le python, donc c'est juste entierement subjectif ou faux.

Citation : nohar

Citation : FirstZero

J'ai lu brièvement ces différents points et je pense qu'il n'a pas tord sur certains point dont un que j'ai moi même fait la remarque qui est celui de déclaration de type (comme int en C/C++).

Wut ?

C'est simplement que le langage a un typage dynamique, ce qui permet de lever plusieurs barrières et gagner beaucoup de temps dans pas mal de cas. Je ne suis pas là pour dire "le typage dynamique c'est mieux dans l'absolu", puisque j'aime autant Haskell (avec son typage autistique) que Python, seulement les deux langages correspondent simplement à des façons de penser, et de travailler, très distinctes.

Je n'ai pas le temps de réagir à la liste point par point pour le moment. Je le ferai probablement plus tard.

Le problème sera à la relecture... Quand tu vois int, tu sais ce que la fonction a renvoyer où directement, sans regarder la valeur (parfois il n'y en a pas) tu seras ce que la variable contiendra. Bon après je ne programme pas depuis très longtemps (moins d'un an) donc je ne peux pas dire si c'est réellement mieux (et puis il y a une question d'habitude aussi qui entre en jeu) mais au départ ceci m'a déstabilisé.

Si la fonction est correctement documentée (et les docstrings sont une façon d'encourager cette pratique), tu peux faire figurer l'info au même endroit que sa déclaration.

Le problème du typage dynamique (ce que l'on peut lui reprocher), ou plutôt, l'avantage d'un typage plus strict, c'est surtout que l'on peut vérifier et éviter certaines erreurs lors de la compilation, sans avoir à exécuter le programme pour cela. En soi, c'est une sécurité, mais une sécurité qui a un prix : cela rend les choses un peu plus compliquées pour faire du code polymorphe.

Tu peux très bien vouloir coder des fonctions assez abstraites pour que leur comportement s'adapte à ce que tu leur passes en argument, et que le type qu'elles renvoie varie lui aussi, de façon à pouvoir les réutiliser plus facilement :

>>> def ajouter(a, b):
...     return a + b
... 
>>> ajouter(2, 3)
5
>>> ajouter('Hello, ', 'World!')
'Hello, World!'
>>> ajouter(5.0, 2.0)
7.0

Dans cet exemple tout bête, j'ai codé une seule fonction au lieu de trois, et si je créais une classe, en voulant qu'elle fonctionne aussi avec une fonction "ajouter", je n'aurais qu'à surcharger son opérateur "+", et je pourrais l'utiliser avec le code que j'ai déjà fait, plutôt que de modifier celui-ci pour qu'il sache s'y adapter. Assouplir le typage à ce point (de façon que tout ce qui intéresse la fonction, c'est que ce que l'on lui passe en paramètre ait les méthodes qu'elle utilise) permet de monter d'un cran dans les niveaux d'abstraction, ce qui peut s'avérer être un réel avantage et un gain de temps considérable.

Pour utiliser ce genre de polymorphisme (plus précisément, c'est du polymorphisme paramétrique), tu aurais besoin, en C++ (en C, c'est juste impossible), de passer par des templates, ce qui, souvent, complique pas mal le code pour pas grand chose, la limite majeure des templates du C++ étant qu'en général, ils complexifient les erreurs de compilation (elles en deviennent assez souvent mystiques, d'ailleurs). D'autres langages permettent d'utiliser ce genre de polymorphisme de façon simple et élégante, tout en restant explicites à la compilation (comme Haskell…), mais cela reste plus direct, plus intuitif, et moins contraignant en Python.

Les templates ne sont pas si difficile que sa . Je pense juste que pour des soucis de relecture, c'est beaucoup mieux de fixer le typages lors de la déclaration de variables.

M'enfin, on pourrait écrire des pages et des pages sur ce qui est bénéfique à ce style ou ce qui ne l'ai pas (et perso j'ai pas envie de le faire ).

Citation : FirstZero

Les templates ne sont pas si difficile que sa .

Le principe en lui-même des templates du C++ est simple, mais la méta-programmation permise par C++ grâce à eux, est compliquée et contre-intuitive à mettre en œuvre (les type-traits, les policies, l'utilisation de typelists…) et donne des erreurs de compilation imbitables. Du coup, tu perds quand même l'avantage premier d'un typage statique.

Citation

pour des soucis de relecture, c'est beaucoup mieux de fixer le typages lors de la déclaration de variables.

Sauf que c'est beaucoup plus contraignant pour faire du polymorphisme paramétrique, je viens de prendre la peine de détailler ce point dans mon post précédent… Au lieu de me répéter la même chose que ton précédent post, tu pourrais juste faire l'effort de lire et de répondre à ce que j'ai dit.

Ce que l'auteur de la liste critique n'est pas le typage dynamique (il ne vanterait pas Lisp) mais les déclarations implicites. Python n'a pas d'équivalent au use strict de Perl par exemple.
Au passage, je ne trouve pas vraiment pertinent de surcharger + pour la concaténation, mais c'est du détail.

Citation : 1337833K

Ce que l'auteur de la liste critique n'est pas le typage dynamique (il ne vanterait pas Lisp) mais les déclarations implicites. Python n'a pas d'équivalent au use strict de Perl par exemple.

C'est pas faux, mais je ne l'ai jamais vu comme une faiblesse du langage. J'utilise Perl au boulot, avec une coding-style qui impose le use strict, mais je n'ai jamais pu remarquer d'avantage particulier à cela (d'autant que, comme Python, Perl a un typage très souple). C'est une sécurité, certes, mais ça reste une considération subjective : ça ne m'a jamais manqué en Python, et je ne la trouve pas spécialement utile dans un contexte dynamique.

Pour ce qui est de la surcharge de +, c'est simplement qu'en Python, on évite de multiplier les opérateurs inutilement. En Perl, avoir des opérateurs séparés pour la concaténation et la multiplication des chaînes de caractères fait du sens puisque c'est une façon de différencier les scalaires entre eux, mais le fait que Python soit plus fermement orienté objet (et typé complètement différemment) rend ceci caduque. Le + et le * sont donc utilisés aussi bien pour les nombres que pour les listes et les chaînes de caractères.
Je trouve que ça se défend, personnellement, mais là aussi, c'est subjectif.

Citation : 1337833K

Ce que l'auteur de la liste critique

Et c'est qui ce mystérieux auteur ?

Citation : nohar

Le + et le * sont donc utilisés aussi bien pour les nombres que pour les listes et les chaînes de caractères.

En même temps, il est surprenant que la fonction standard sum n'admette pas de chaînes :

>>> sum([0,0])
0
>>> sum(["zero","zero"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>>

(pas très orthogonal je trouve)

De même, il est curieux que la fonction standard min, elle, accepte les chaînes et il est surprenant qu'elle admette une signature différente de celle de sum, ie tu peux faire min(4,19,7) mais pas sum(4,19,7) :

>>> min(4,19,7)
4
>>> sum(4,19,7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum expected at most 2 arguments, got 3
>>>

Citation : Gow3

Bonsoir,

voilà cela fait quelques temps que je programme en c++ et python, à chaque fois j'ai envi de changer un peu d'air entre ces deux langages. Alors voilà, le but de ce topic n'est pas d'en faire un troll, cependant j'hésite à choisir python... J'ai peur qu'on me prenne pour un débutant : "Python pour les nuls","c'est un langage de script ça pue !", "les hackeurs et créateurs de logiciels et jeux videos evitent ce langage" , "aucun mérite à l'apprendre : trop facile !" etc.

Donc voilà je cherche une réponse qui me fasse envi de choisir Python étant donné que je le trouve plus sympa que le c++ mais que c'est un bazard total au niveau des versions et des compatibilités, de même pour créer un exécuteur.

C'est faux, justement je suis à la recherche d'un stage "Développeur Linux / Administrateur Systèmes et Réseaux" et dans la plupart des annonces, parmi les compétences requises il y a Python. A la base, je ne connais pas trop ce langage, mais en ce moment je suis amené à travailler avec car je dois réaliser un programme générant des attaques réseau "Man in the middle", et c'est plutôt le langage approprié pour ce genre de choses.

Citation : nohar

Citation : FirstZero

Les templates ne sont pas si difficile que sa .

Le principe en lui-même des templates du C++ est simple, mais la méta-programmation permise par C++ grâce à eux, est compliquée et contre-intuitive à mettre en œuvre (les type-traits, les policies, l'utilisation de typelists…) et donne des erreurs de compilation imbitables. Du coup, tu perds quand même l'avantage premier d'un typage statique.

Citation

pour des soucis de relecture, c'est beaucoup mieux de fixer le typages lors de la déclaration de variables.

Sauf que c'est beaucoup plus contraignant pour faire du polymorphisme paramétrique, je viens de prendre la peine de détailler ce point dans mon post précédent… Au lieu de me répéter la même chose que ton précédent post, tu pourrais juste faire l'effort de lire et de répondre à ce que j'ai dit.

oui j'ai lu ne t'inquiète pas . Le polymorphisme paramétrique peut être bien mais parfois cela peut devenir ingérable (tout le monde ne prends pas la peine de lire une documentation au complet par exemple). Comme on l'a dit, sa a des qualités mais aussi des défauts.

Citation

Le polymorphisme paramétrique peut être bien mais parfois cela peut devenir ingérable (tout le monde ne prends pas la peine de lire une documentation au complet par exemple). Comme on l'a dit, sa a des qualités mais aussi des défauts.

Quel est le foutu rapport entre le polymorphisme paramétrique et la documentation ? Inutile de répondre à cette question, elle est rhétorique : il n'y en a aucun. Ce serait cool aussi d'éviter de sortir des phrases bateaux dans le seul but de ne pas avoir à avouer que tu ne sais absolument pas de quoi tu parles.

D'une, parce que c'est grillé instantanément ; de deux, parce que ce n'est pas comme ça que tu progresseras ; de trois, parce que ça évite de noyer la conversation dans des posts inutiles.

@candide : en effet, je ne m'étais jamais fait cette remarque, mais présenté comme ça, ça saute aux yeux et c'est effectivement un manque de cohérence. La raison doit sûrement être due à l'utilisation "majoritaire" de ces fonctions : à vue de nez, on dirait qu'ils ont fait le choix de rendre min et max compatibles avec l'utilisation la plus courante (deux arguments seulement), où il semble naturel de passer ces deux arguments plutôt qu'une liste mais je n'en mettrais pas ma main à couper, et ce n'est pas forcément un bon argument. Le plus logique aurait probablement été de faire des fonctions sum, min, max à nombre variable d'arguments, à côté de fonctions isum, imin, imax prenant en argument un itérable…

Citation : FirstZero

Le polymorphisme paramétrique peut être bien mais parfois cela peut devenir ingérable (tout le monde ne prends pas la peine de lire une documentation au complet par exemple). Comme on l'a dit, sa a des qualités mais aussi des défauts.

Sans regarder le rapport entre la doc et le polymorphisme paramétrique (il n'y en a pas un poil de c..), peux-tu me dire quel est le défaut du polymorphisme paramétrique?

Polymorphisme paramétrique (que je préfère au mot générique personnellement), un bien grand mot en POO, pour pas grand chose, j'ai du regarder sur un site pour savoir ce que s'était et en fait je me souviens en avoir fais en C++ avec les templates. Mon dieu quelle horreur. Enfin bref plutôt que de critiquer le C++, je préfère dire que cette façon de penser en python est bien appréciable, quoique comme le dis Candide ça n'est pas une généralité du langage.

et là je regarde plus bas

Citation : nohar

Le principe en lui-même des templates du C++ est simple, mais la méta-programmation permise par C++ grâce à eux, est compliquée et contre-intuitive à mettre en œuvre (les type-traits, les policies, l'utilisation de typelists…) et donne des erreurs de compilation imbitables. Du coup, tu perds quand même l'avantage premier d'un typage statique.

Le principe oui, heureusement que tu le dis, mais la faisabilité

C'est comme dire que la POO en python est pas la même qu'en C++, on peut aussi dire l'inverse ...

Citation : 1337833K

Citation : Anonyme

Le système de paquets de Python est fautif.

J'ai pas compris le rapport des paquets avec la faute qui est expliquée ensuite, cf. ci-dessous.

Citation : 1337833K

Citation : Anonyme

Le système de paquets de Python est fautif. Tapez time.sleep=4 au lieu de time.sleep(4) et vous venez de détruire la fonction sleep avec une faute triviale.

Mais ça se répare assez facilement :

>>> import time
>>> time.sleep(1)
>>> time.sleep=4
>>> time.sleep(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable
>>> reload(time)
<module 'time' (built-in)>
>>> time.sleep(1)
>>>

C'est plus gênant pour des identificateurs built-in comme max qu'on a tendance à affecter malencontreusement mais c'est encore réparable

>>> max=range(42)[-1]
>>> max
41
>>> max(5,6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable
>>> max=__builtins__.__dict__['max']
>>> max(5,6)
6
>>>