De quels messages parles-tu ? Si tu parles des exceptions : entre une traceback qui indique exactement où tu es (nom du fichier + numéro de ligne + ligne de code pour chaque fonction de la pile) et "Segmentation fault", j'ai fait mon choix :-)
Comparons ce qui est comparable...
En C , je trouve les messages *du compilateur* plus clairs.
En python, ya pas de compilation (ou du moins, pas à mon niveau de connaissance).
Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)
Voici le diff en question.
Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).
C'est vrais que c'est dans le module pyUnit.
def Build(self):
ret = True
print "Compilation of %s..." % self.name
Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction.
C'st exactement là-dessus que je perdais un temps fou, a tel point que je me suis fait un post-it avec les modules pour chaque fonction.
Et puis, la doc Python est plus agréable à lire que les manpages C je trouve.
Là pour le coup je ne suis pas du tout d'accord ! Pour moi rien de plus rapide de faire man 2 open et tu as , dans le terminal, le ou les .h qu'il faut inclure & la description des arguments.
La doc python elle est très bien, sauf que quand tu lance une recherche sur open ya 100 réponses ! Il faut déjà savoir quel module que tu cherche. Et c'est sur le net... si t'a pas le net c'est pas pratique (tu peux la télécharger, mais alors tu fait comment pour chercher ?)
Au final, moi je trouve qu'il y a du pour & du contre dans les 2 langages, et pour moi le python n'est pas l'eldorado de la programmation tel qu'il est parfois présenté...
[^] # Re: Avantage
Posté par C. OB (site web personnel) . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 0.
Comparons ce qui est comparable...
En C , je trouve les messages *du compilateur* plus clairs.
En python, ya pas de compilation (ou du moins, pas à mon niveau de connaissance).
Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)
Voici le diff en question.
Je précise que la cible est *python 2.3* , et je développe sous python 2.5. (Non, on peux pas upgrader... Le code doit être compatible avec les 2 versions).
C'est vrais que c'est dans le module pyUnit.
- self._tests = unittest.TestLoader().loadTestsFromTestCase(CA_TestCase)
+ self._tests = unittest.TestLoader().loadTestsFromTestCase(CA_TestCase)._tests
def Build(self):
ret = True
[...]
- self._tests = unittest.TestLoader().loadTestsFromTestCase(Cyclictest_TestCase)
+ self._tests = unittest.TestLoader().loadTestsFromTestCase(Cyclictest_TestCase)._tests
def Build(self):
ret = True
print "Compilation of %s..." % self.name
Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction.
C'st exactement là-dessus que je perdais un temps fou, a tel point que je me suis fait un post-it avec les modules pour chaque fonction.
Et puis, la doc Python est plus agréable à lire que les manpages C je trouve.
Là pour le coup je ne suis pas du tout d'accord ! Pour moi rien de plus rapide de faire man 2 open et tu as , dans le terminal, le ou les .h qu'il faut inclure & la description des arguments.
La doc python elle est très bien, sauf que quand tu lance une recherche sur open ya 100 réponses ! Il faut déjà savoir quel module que tu cherche. Et c'est sur le net... si t'a pas le net c'est pas pratique (tu peux la télécharger, mais alors tu fait comment pour chercher ?)
Au final, moi je trouve qu'il y a du pour & du contre dans les 2 langages, et pour moi le python n'est pas l'eldorado de la programmation tel qu'il est parfois présenté...