C'est le titre du hors-série dédié à Python en vente dans toutes les librairies en France pour 6,50€ (sauf dans la gare de Sens).
Introduction
Introduction : Python, un monstre de langage
Nouveautés de Python 2.6
Nouveautés de Python 3
Éducation
Apprenez d’abord Python !
Science
Python comme langage scientifique
Réseau
Python et le réseau
Code(s)
Packager et diffuser son application Python
Trucs et astuces
Ctypes et Python
Présentation de la Zope Component Architecture
Vous pouvez en avoir un aperçu (petites images JPEG) chez l'éditeur : http://www.ed-diamond.com/produit.php?produit=609
Ils en parlent :
http://www.afpy.org/Members/tarek/linux-mag-hs-python
http://gael-varoquaux.info/blog/?p=91
http://ccomb.gorfou.fr/hors-serie-python-linux-mag
http://www.haypocalc.com/blog/index.php/2009/01/27/185-hors-(...)
http://www.toolinux.com/lininfo/toolinux-information/revue-d(...)
Un dossier dédié au développement web suivra dans le Linux Mag n°114 (mars 2009), et un autre sur PyGame (jeux vidéos) dans Linux Mag n°115.
Journal Explorez les richesses du langage Python
28
jan.
2009
# J'hésite...
Posté par Elfir3 . Évalué à 10.
[^] # Re: J'hésite...
Posté par Victor STINNER (site web personnel) . Évalué à 2.
[^] # Re: J'hésite...
Posté par Mouns (site web personnel) . Évalué à 1.
Tout compte fait, les films de Romero sont possiblement prophétique !
( tiens, c'est l'heure de promener mon chien )
[^] # Re: J'hésite...
Posté par Aefron . Évalué à 2.
# Puissance de python
Posté par tfeserver tfe (site web personnel) . Évalué à 10.
subprocess.call(['/usr/bin/perl', '....']);
[^] # Re: Puissance de python
Posté par Christophe B. (site web personnel) . Évalué à 3.
je n'ai pas encore compris comment on note mais je met 20/20
A+
chris
# Bravo !
Posté par GeneralZod . Évalué à 10.
Ma critique (dans le sens noble du terme):
* Nouveauté de Python 2.6/3: les principaux concepts sont là, c'est bien expliqué avec des exemples clairs. Python 3 étant principalement là pour nettoyer le langage des incohérences accumulés au cours du temps, ne pas s'attendre à des changements radicaux, idem pour Python 2.6 qui est une release de transition.
* Apprenez d'abord Python: comme le présente son auteur, c'est un plaidoyer qui explique pourquoi choisir Python comme langage d'introduction à la programmation. L'annexe donne des conseils pour apprendre et enseigner Python. C'est très bien argumenté, la bibliographie fait une page à elle seule. À faire lire à vos collègues ou à vos enseignants !
l'article que j'ai préféré, même si on prêchait un convaincu. :o)
* Python comme langage scientifique: ce thème justifierait à lui seul un HS dédié, donc ça va à l'essentiel, et présente les principaux paquets et outils. Donc sur certains passages comme ceux sur SciPy et SimPy ça va un peu vite.
Python a un gros potentiel dans ce domaine, il surpasse largement les mastodontes comme Matlab, mais ce dernier a un avantage clé: un nombre impressionnant de toolbox.
* Python et le Réseau: un tutoriel sur l'utilisation des modules réseaux standard puis de Twisted.
Je tire mon chapeau à l'auteur de l'article pour la partie sur Twisted, c'était pas évident de présenter un paquet aussi complexe de façon à ce que ce soit compréhensible par des néophytes.
* Packager et diffuser son application Python: le nom de l'auteur à lui seul est un gage de qualité. L'article ? très pédagogue, on part du plus simple au plus compliqué (distutils, diffusion sur le PyPI). Je ne sais pas si c'est par modestie, mais l'auteur n'a pas cité son dernier opus "Expert Python Programming" qui consacre un chapitre entier à la question.
* Trucs et astuces: un recueil de petites "recettes" et de conseils. C'est destiné à un public de néophyte, mais j'ai bien aimé le paragraphe sur "with".
* Ctypes et Python: ctypes est un module très pratique permettant d'appeler directement du code C en Python. L'écriture d'extensions en C est assez contraignante dans la plupart des langages (semi) interprété, c'est même ce qui m'a fait préféré C# à Java.
C'est une très bonne introduction à ctypes, bon point pour l'auteur, il présente find_library() qui évite pas mal de gruikeries dans le chargement de modules.
* l'article sur Zope: je ne l'ai pas lu et je ne le lirai pas donc je ne dirais rien. Je suis complétement allergique à Zope.
Ma note finale: 9/10 Compte-tenu du nombre de page limité, c'est mérité.
[^] # Re: Bravo !
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
Je pense que tu devrais, car le principe de Component Architecture est très intéressant.
Je dirais que c'est une couche au dessus de la POO. Intéressant même dans un contexte
qui n'a aucun lien avec Zope.
Peut être qu'il faudrait renommer Zope Component Architecture en Python Component
Architecture pour élargir l'auditoire :)
[^] # Re: Bravo !
Posté par benoar . Évalué à 6.
[^] # Re: Bravo !
Posté par Gniarf . Évalué à -3.
[^] # Re: Bravo !
Posté par ccomb (site web personnel) . Évalué à 3.
[^] # Re: Bravo !
Posté par GeneralZod . Évalué à 3.
Pas d'accord, tu peux parfaitement utiliser les designs patterns cités sans la ZCA.
Après, la ZCA te donne un cadre prédéfini pour les utiliser, un peu comme ce qui existe déjà pour J2EE. Je n'ai rien contre la ZCA en particulier, je ne connais pas donc je ne me permet pas de juger.
De plus, je reconnais que ce n'est pas très rationnel, mais la simple mention "Zope" suffit à freiner mes ardeurs. Ça n'enlève rien au fait que Zope est un bon framework d'entreprise, qu'il a des qualités, mais c'est pas mon truc ni même mon domaine d'activité principale.
D'ailleurs, j'ai pas fini de lire "Expert Python Programming" qui en parle tout à la fin.
> au lieu d'hériter, on adapte. C'est souvent beaucoup plus propre.
+1
[^] # Re: Bravo !
Posté par gawel (site web personnel) . Évalué à 5.
Un bon exemple est zope.sendmail que j'utilise dans une appli pylons pour envoyer des mails en asynchrone sans avoir eu besoin de pondre trop de code.
repoze.who et repoze.what, eux aussi basé sur la ZCA permettent de gérer l'authentification d'une application dans un middleware wsgi et tendent à devenir un standard dans le monde pylons / TG2.
Un autre exemple est zope.interface qui est utilisé dans twisted.*
Ignorer ces paquets de qualité hautement testé et plutôt bien documenté n'est pas forcément judicieux. Surtout si on utilise python pour le web.
Après, ce que j'en dis.. :)
[^] # Re: Bravo !
Posté par GeneralZod . Évalué à 3.
J'ai commencé à le survoler, mais il me faut un peu plus de temps pour le digérer.
[^] # Re: Bravo !
Posté par lhardy philippe (site web personnel, Mastodon) . Évalué à 3.
Dans le cadre de mon travail j'ai du code python à maintenir et à étendre.
Je pensais trouver un bout de tutoriel de prise en main de python, mais ce n'est pas le cas.
Je ne suis cependant pas déçu parce que la partie réseau et sa sous-partie python twisted m'a beaucoup intéressé.
De plus l'argumentaire sur python comme langage d'apprentissage m'a vraiment convaincu.
Et là aussi ça tombe bien car je compte mettre en place des sessions d'apprentissage de la programmation généraliste au sein de notre lug.
Cela me donnera aussi un réponse à donner à un de nos membre qui me demandait quel est le bon langage pour débuter. Il voulait faire du java, je ne l'en avais pas dissuadé, mais je m'aperçois bien que rien que la séparation compilation/exécution est un vrai frein. Il lui fut proposé d'apprendre le C, là je trouvais que c'est un peu fort pour un débutant. Et avec des références pour débuter... J'ai été bien en peine de lui citer des bouquins pour débuter en Java, parce que simplement je suis un développeur et non un professeur... Avec ce Hors Série, il y a de quoi démarrer..
Donc je ne suis pas déçu de mon achat.
[^] # Re: Bravo !
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Bravo !
Posté par Eric (EOL) LEBIGOT (site web personnel) . Évalué à 2.
# HS Python
Posté par patrick_g (site web personnel) . Évalué à 5.
Je regrette toutefois le fait que l'article dédié au dev web n'ait pas été intégré au hors-série et qu'il ne soit publié que dans un futur numéro de Linus Mag. Cela aurait été vraiment plus cohérent et logique de l'avoir dans le hors-série (d'ailleurs l'édito du hors-série exprime le même regret).
# Merci pour l'information
Posté par plagiats . Évalué à 4.
Le python est vraiment un langage abordable pour les personnes qui comme moi n'ont pas de formation de développeur/ingé, il permet de faire rapidement des choses que d'autres s'arrachent les cheveux à essayer de faire avec Automator par exemple.
Il permet de mieux comprendre la POO en la mettant en pratique sans avoir à écrire des tonnes de code pour 3 fois rien (c#? java?), et pour un débutant c'est génial.
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . Évalué à 5.
[^] # Re: Merci pour l'information
Posté par Ririsoft . Évalué à 7.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pour l'information
Posté par allcolor (site web personnel) . Évalué à -2.
que j'aurais mis l'ordre :
Python, C/C++, java
Bon tant qu'on y est au niveau avis de comptoir, moi je mets:
java, C++, C, Python
Pourquoi ?
1- Java ça fait 10 ans que je programme, je connais très bien, je vais vite, je vais à l'essentiel. Bcp de libs dispo, pas/peu de redondance sur ce qui est standard, rapidité de compil, gestion mémoire, reflection, proxy dynamique simple à faire et j'en passe.
2- C++, j'en fais aussi depuis plus longtemps que java mais plus chiant pour pleins de trucs, comme les 250 types strings utilisées par les 4000 libs dispo qui font la même chose mais différemment, la gestion de la mémoire, les pointeurs, les != libs de smart pointers, le temps de compil, le déploiement etc... Mais ça reste bien et fun quand même.
3- Le C ben l'oo en moins
4- Python, je ne programme pas en python alors niveau productivité il est forcément en dernier.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pour l'information
Posté par lhardy philippe (site web personnel, Mastodon) . Évalué à 4.
Un langage pratique vient avec de bonnes et nombreuses librairies.
Java, python, perl, C/C++ sont dans le lot.
Puis il y a des langages dédiés à des sujets particuliers, SQL par exemple...
Je ne crois pas qu'il y ait de langage ultime, et de toutes les façons au cours d'une carrière en informatique on est souvent appelé à toucher un peu de tout.
En fait le bon langage est souvent celui du projet sur lequel on est amené à travailler, on n'a pas tous la chance de partir 'from scratch'.
Et là ça tombe bien j'ai justement besoin de faire du python.
Je crois que je vais investir 6,50 euros pour mon avenir :-)
Après on pourrait faire une étude psychologique sur certaines raisons d'utiliser un langage plutot qu'on autre.
L'utopie de bien des informaticiens ( et je ne m'exclue pas du lot ) c'est d'inventer son propre langage et de démontrer à la planète entière que c'est le meilleur...
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . Évalué à 2.
De quoi tu parles ? Un code Python 2.0 (2000) fonctionne encore sur Python 2.6 (2008). D'ailleurs, je pense qu'on peut écrire du code qui fonctionne sur Python 1.5 (1999) et 3.0 (2009). Les changements qui brisent la compatibilité surviennent à tous les changements de version majeurs : 2.0 (2000) et 3.0 (2009), sachant que la branche 2.x est encore en développement en ne va pas s'arrêter avant quelques années.
En général, les nouveautés sont des ajouts et non des suppressions. Exemple : dans Python 2.6 on peut écrire 0o10 (8 en octal), avant on écrivait 010... mais l'ancienne syntaxe est encore autorisée. Donc l'ancien code continue de fonctionner.
Le vrai problème vient des modules Python écrit en C qu'il faut recompiler pour chaque nouvelle version de Python, et l'API change un peu à chaque fois. J'ai entendu pas mal de monde qui conservait une ancienne version de Python car un module précis ne fonctionnait pas sur la nouvelle version de Python. Solution : se passer de ces modules ou les réécrire en Python (ex: avec ctypes), mais j'avoue que cette solution n'est pas faisable pour de gros modules si on n'a que peu de temps devant nous.
Il me semble que Java fait également attention à la compatibilité ascendante.
[^] # Re: Merci pour l'information
Posté par windu.2b . Évalué à 2.
Oui, il y a compatibilité de Java 1.2 à Java 6.
C'est même un reproche qui lui est fait : d'y faire trop attention et donc de se trainer des boulets (Java 1.2 à 1.4)
[^] # Re: Merci pour l'information
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Merci pour l'information
Posté par plagiats . Évalué à 1.
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Hum, ce n'est pas ce que je voulais dire : la compilation des bibliothèques (Python) écrites en C pose problème. L'API de ces bibliothèques est inchangée.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pour l'information
Posté par GeneralZod . Évalué à 1.
Faux, Python suit une spécification (Cf ci-dessous)
> un bug est considéré dans la spec car il est dans l'implémentation
Tu es courant qu'il existe un mécanisme normalisé pour gérer l'évolution du langage ? (Les PEP aka Python Enhancement Proposals). Ça marche comme les JSR de Java sauf que c'est un peu plus ouvert, donc si on suit ton raisonnement, si il y a un bug dans l'implémentation Java de Sun, il est considéré comme faisant partie de la spec ?
http://www.python.org/dev/peps/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pour l'information
Posté par GeneralZod . Évalué à 1.
[^] # Re: Merci pour l'information
Posté par TImaniac (site web personnel) . Évalué à 1.
C'est pas parcque tu mets le mot "specification" que ca devient une spécification de qualité.
[^] # Re: Merci pour l'information
Posté par plagiats . Évalué à 2.
[^] # Re: Merci pour l'information
Posté par TImaniac (site web personnel) . Évalué à 3.
Bref c'est un ensemble hétérogène d'information sans cohérence entre elles et c'est Van Rossum qui a le dernier mot.
C'est vraiment oser d''appeler cet "ensemble" spécification et comparer avec ce que fait l'ISO l'ECMA ou l'OASIS en matière de spécification.
[^] # Re: Merci pour l'information
Posté par GeneralZod . Évalué à 5.
C'est exactement la même chose avec Java.
Tu peux proposer une PEP (JSR), elle est débatue par la communauté (JCP) soit elle adoptée soit elle est accepté. Le mainteneur principal GvR (Sun) a le dernier mot, mais tout passe par une PEP pour décrire la spécification. Comme Java, il y a un jeu de tests pour tester la conformité d'une implémentation.
La différence, c'est que Java est contrôlé par des industriels (Sun, IBM, Oracle, BEA etc...) et Python par la communauté Python, c'est quand même plus sympa ?
Mais bizarrement, on se pose la question de savoir si il existe une spécification pour Python et pas pour Java.
> C'est vraiment oser d''appeler cet "ensemble" spécification et comparer avec ce que fait l'ISO l'ECMA ou l'OASIS en matière de spécification.
Le fait que ça ne passe par un organisme de standardisation, ne veut pas dire qu'il n'y a pas de spécifications. Java n'est pas passé par un organisme de normalisation comme l'ISO ou l'ECMA et personne ne hurle pas "java sapusaipanormaliséparliso".
Ce fil est en train de devenir un ramassis de conneries et de trolls sur Python. Faut vraiment être un enculeur de drosophiles pour comparer Python à C, C++ ou Java. Chacun de ses langages a ses domaines de prédilection et rien n'empêche de les utiliser ensemble selon les besoins. Un bon développeur Python n'a jamais craché sur le C et le C++ (ne serait-ce que pour coder une extension), d'ailleurs, le mariage C/Python ou C++/Python (merci Boost) est un bon compromis entre performance et productivité.
On aurait trollé sur Python vs Perl/Ruby, j'aurais à la rigueur compris vu que ces langages jouent dans la même "catégorie".
À croire que les rubyistes et les mongueurs sont plus matures que les fanboys Java ou DotNet.
[^] # Re: Merci pour l'information
Posté par TImaniac (site web personnel) . Évalué à 4.
Jamais dit le contraire.
Je compares avec la langages standardisés/normalisés.
Python par la communauté Python, c'est quand même plus sympa ?
Bof. Les industriels ont une bien meilleur vision pour moi des contraintes de maintenance sur le long terme et des implications de tel ou tel changement.
Mais bizarrement, on se pose la question de savoir si il existe une spécification pour Python et pas pour Java.
Ben Java, y'a un document de référence, il est où le document de référence sur Python ? Le truc qui me défini le plus formellement possible tout le langage ?
Le fait que ça ne passe par un organisme de standardisation, ne veut pas dire qu'il n'y a pas de spécifications.
Je dis pas le contraire. Je dis juste que c'est pas comparable le résultat obtenu.
Ce fil est en train de devenir un ramassis de conneries et de trolls sur Python.
C'est en plein dans le sujet du journal : le journal présente des "nouveautés" et met en évidence une nouvelle version du langage qui n'est pas compatible avec la version d'avant. Donc tout naturellement on discute compatibilité toussa. Et la comparaison avec d'autres langages est tout à fait pertinente. Notes que l'on compare les processus de spécification, pas les qualités techniques du langage en soit.
[^] # Re: Merci pour l'information
Posté par Boa Treize (site web personnel) . Évalué à 1.
Le document qui s'en rapproche le plus :
http://docs.python.org/reference/index.html
Également (mais moins formel) :
http://docs.python.org/library/index.html
Le tout étant versionné (les liens donnent accès à la version "en production", c'est à dire la 2.6).
Je n'ai pas eu l'occasion d'avoir beaucoup de retours d'expérience sur Python dans de grandes entreprises, le seul que j'aie eu faisait état d'un problème de changement d'implémentation dans les libs quand ils ont voulu monter en version leur installation de Python, ils en avaient gardé un mauvais souvenir. (Mais vu l'entreprise concernée, ça ne donne aucune indication sur le réel niveau de la difficulté rencontrée.)
[^] # Re: Merci pour l'information
Posté par GeneralZod . Évalué à 2.
ça permet de mettre à jour en douceur ses modules et scripts sans devoir tout casser.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci pour l'information
Posté par GeneralZod . Évalué à 4.
For a PEP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement.
2. A l'exception des PEPs "informatives", une fois adopté, elle n'est plus modifiable.
When the reference implementation is complete and accepted by the BDFL, the status will be changed to "Final".
Par contre, une PEP peut remplacer une précédente:
PEPs can also be replaced by a different PEP, rendering the original obsolete. This is intended for Informational PEPs, where version 2 of an API can replace version 1.
Seul les PEPs "informatives" sont toujours active, pas les PEPs "techniques".
Some Informational and Process PEPs may also have a status of "Active" if they are never meant to be completed. E.g. PEP 1 (this PEP).
3. Tu confonds norme et standard industriel, le premier est publié auprès d'un organisme indépendant, le second par des professionnels. C ISO est une norme, Java est un standard industriel, pourtant les deux langages possédent bel et bien une spécification.
Je ne vois en quoi GvR et la communauté Python seraient moins fiables que Sun et sa bande de grosses entreprises.
Python ne prétends pas être une norme, mais un langage avec des spécifications concrètes que tout le monde est libre de réimplémenter.
[^] # Re: Merci pour l'information
Posté par ckyl . Évalué à 3.
La normalisationqui est le fait d'établir des normes et standards industriels, c'est-à-dire un référentiel commun et documenté destiné à harmoniser l'activité d'un secteur.. C et Ada sont normalisés auprès de l'ISO. Java à sont propre comité, le JCP. Pour python je ne connais pas suffisamment les détails. Savoir lequel des processus de l'ISO ou du JCP sont le plus ouvert est laissé en exercice aux lecteurs. Dans tout les cas les spécifications existes.
Je ne sais pas pour python, mais pour Java un bug dans l'implémentation de référence est un bug. C'est très simple tu as une spec. À partir de cette spec une suite de test (TCK) est faite, une implémentation est conforme si elle passe la suite de test.
L'implémentation de ces normes par les compilateurs et la disponibilité des bibliothèques standard sur des plateformes moderne. Ce n'est pas par ce que le C89 ou Ada83 sont normalisés à l'ISO que du code de cette époque est toujours compilable. C'est le choix des compilateur de toujours supporter les anciens standards. Gcc pourrait très bien décider de ne plus supporter le C89 un jour. Avoir une norme est un prérequis mais n'est pas suffisante.
Notons que la partie syntaxique/lexicale du langage n'est qu'une toute petit partie de l'iceberg. L'évolution des bibliothèques standard est tout aussi importante. Si des changements non backward compatibles sont fait aux bibliothèques standard ca devient un peu plus compliqué à gérer les anciens standards. Du coup cela peut impliquer de se trimbaler des API merdiques et totalement délirantes pendant 30+ années (qui à parlé de la libc ?).
Et enfin tu as les bugs des implémentations. Ton programme peut tomber en marche à cause d'une zone floue dans la spec ou tout simplement d'un bug présent dans une release donnée du compilateur/libs. En passant sur une autre implémentation, il va exploser en vol. Dans un monde parfait ca ne devrait pas exister, dans le monde réel si. Toutes les implémentations sont buggées et toutes les specs ont des zones floues.
J'aimerai que tu me démontres en quoi Java se préoccupe moins de la pérennité du code legagy que C ou Ada. C'est presque ce qu'on leur reproche...
[^] # Re: Merci pour l'information
Posté par Boa Treize (site web personnel) . Évalué à 1.
Python aussi se traîne des API foireuses depuis pas mal d'années. C'était quand même l'objectif de Python 3.0 de faire enfin le ménage.
Globalement les PEP sont le pendant des JCP (ou est-ce l'inverse ? :-)), et de nombreux PEP donnent lieu a des tests qui peuvent être utilisés par diverses implémentations de Python. Par contre, ayant moins de pression industrielle et moins d'implémentations concurrentes, il n'y a que l'implémentation C Python classique qui les passe tous (et encore, il reste des bugs). Il est clair aussi que des tests pourraient encore et toujours être ajoutés. (Mais va voir dans le répertoire test de ta lib Python, y'a quand même une belle dose.)
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . Évalué à 4.
En quoi est-ce un problème ? Ton code 2.1 fonctionnera toujours. Tu n'as pas à modifier ton code.
que de la 2.6 à la version 3.0, il n'y a plus de compatibilité
C'est un choix : la version 3 brise la compatibilité pour corriger les erreurs du passé.
Qu'à partir de maintenant, il faudra réécrire les programmes pour être compatible 3.0
Non, la branche 2.x continue d'être maintenue et il n'est pas prévu d'arrêter son développement. Pour information, la branche 2.x est la branche principale (trunk), contrairement à la branche 3.x qui est à part (branches/py3k).
Cela veut aussi dire que la référence c'est l'implémentation de guido et que personne d'autre ne peut être sur de correspondre à la spec
Sais-tu qu'il existe d'autres implémentations de Python que CPython (l'implémentation de référence écrite en C) ? IronPython (.NET), Jython (Java), PyPy (Python), ... Il existe une ÉNORME suite de tests pour vérifier la compatibilité (Lib/test/*py : ~430 fichiers contenant chacun plusieurs dizaines de tests). On s'en sert pour mesurer le niveau de compatibilité avec CPython : PyPy est proche du 100% (genre 99% je crois) alors que PyPy a été réécrit depuis zéro.
Si on prend plus précisément l'exemple des versions 2.x et les sections "Porting to Python 2.x" : (...)
Je connais mal ces documents, mais c'est souvent des corrections de bug (disons des comportements qui n'étaient pas prévus). On peut voir ça comme une rupture de la compatibilité (et oui, c'est le cas). Mais c'est voulu pour augmenter la qualité des language (et des logiciels écrit en Python). Un langage trop laxiste (allez, disons PHP) est source de problèmes difficiles à corriger et comportements inattendus.
Les changements sont quand même mineurs et rapides à corriger. D'ailleurs, c'est des cas particuliers qui impactent peu de projets.
J'ai écrit du code pour Python 2.4 (projet de +25.000 lignes) : il fonctionne sur Python 2.5 et 2.6 sans que j'ai eu à le modifier.
Bon, je peux me tromper, j'ai peu d'expérience dans la migration d'un gros projet 2.n => 2.(n+1). Je sais que Zope est bloqué en Python 2.4 par exemple. Il me semble qu'il y a un projet de migration vers 2.5 (alors que la dernière version stable de Python est la 2.6 :-/).
[^] # Re: Merci pour l'information
Posté par pasBill pasGates . Évalué à 2.
Ah ben faut mieux regarder, j'ai fait la transition il y a un peu plus de 10 ans, meme sous la torture je ne reviendrais pas en arriere.
[^] # Re: Merci pour l'information
Posté par allcolor (site web personnel) . Évalué à -1.
Ou est-ce parce que j'ai mis que c'est un avis de comptoir, si c'est le cas le message auquel je répondais l'était tout autant sans en plus expliquer le pourquoi.
Est-ce parce que j'ai mis Python en dernier niveau productivité de mon point de vue ? c'est vrai de mon point de vue étant donné que je ne programme pas en Python donc je pourrais difficilement être productif actuellement avec.
Enfin si ce message-ci est inutile certainement, je ne vois pas en quoi le précédant l'était.
Merci d'avoir lu jusqu'ici et retenu votre doigt.
# L'histoire de python
Posté par wilk . Évalué à 5.
http://python-history.blogspot.com
# Virtualisation ?
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 3.
WeeChat, the extensible chat client
# Login me manque...
Posté par Leccux . Évalué à 2.
J'ai une petite pensé pour Login et ses HS.
Un numéro = un langage est vraiment une bonne formule pour avoir une "culture" (globale et approximative) du langage et donner les armes pour approfondir.
Espérons que le succès de ce numéro ouvrira la voie à d'autres...
[^] # Re: Login me manque...
Posté par CrEv (site web personnel) . Évalué à 4.
C'est pas parce que c'est python que c'est le premier numéro du genre hein ...
Il y a eu, il n'y a pas si longtemps, un HS sur ruby par exemple
Ok, en fait c'était en novembre/décembre 2007 : http://www.ed-diamond.com/produit.php?produit=512
Et avant il y avait déjà eu un hors série sur php5 en septembre/octobre 2004 : http://www.ed-diamond.com/produit.php?produit=367
# Quel magazine ?
Posté par Boa Treize (site web personnel) . Évalué à 5.
(Ah ok, c'est devinable tout en bas de la news...)
[^] # Re: Quel magazine ?
Posté par lolop (site web personnel) . Évalué à 1.
GNU Linux Magazine / France
Hors Série N°40
Janvier/Février 2009
6,50€ dans les bonnes librairies
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Et en complement...
Posté par fabricius . Évalué à 2.
http://www.ulg.ac.be/cifen/inforef/swi/python.htm
Et n'hesitez pas a l'acheter (enfin tant qu'il en reste, vu la situation de Oreilly france...) pour soutenir l'auteur!
# Critique
Posté par phoenix (site web personnel) . Évalué à 1.
Merci d'avoir averti, j'ai acheté le magazine, car j'aime bien Python (de ce que j'en entend parler) comme langage de script pour des programmes de petites tailles, et avait également l'intention d'apprendre ce langage (que je connais peu).
J'ai néanmoins une critique à faire sur l'article "Apprenez d'abord Python !".
Je trouve que dans cet article, les exemples sont souvent les mêmes et parfois faux :
- Exemple n°1 : python ne se compile pas, les erreurs arrivent à l'interprétation : Là je suis d'accord, ca peut être un avantage pour début, rien à dire (à part que ça revient souvent dans l'article).
- Exemple n°2 : Comparer le Hello world C a un Hello world Pyhon, et faire une généralisation abusive pour dire que le C et plus verbeux. Je suis d'accord sur l'exemple du Helloworld, mais il faudrait d'autres exemples (et pas toujours le même) justifiant de la verbosité du C par rapport au Python. Par ailleurs, je ne crois pas que c'est toujours le cas, surtout avec de bon toolkit. (ce point 3). Ce point revient d'ailleurs plusieurs fois dans l'article.
- Exemple n°3 : On parle par exemple de la simplicité du python et de pouvoir faire un for element in list, et dire que en C tu ne peux faire que des boucles itératives. Je trouve cet affirmation un peu fausse. J'utilise le toolkit Qt, (qui rajoute une surcouche au C++ mais cela reste du C++), et je peux très bien faire des foreach( element, list ) { }.
Enfin, en C++/Qt, tout comme en Java, on peut lire un fichier sans effort dans une liste (qui n'est pas de taille fixe), et faire un list.sort() (ou même un qSort(list)) sans devoir réécrire un algorithme de trie ou gérer la taille du tableau (cf la partie "Le plaisir de faire beaucoup avec juste l'effort suffisant").
Pour le reste de l'article, je le trouve intéressant, et par exemple, les parties comme la compilation sont véridique, ainsi que le fait qu'il n'y ai pas de ponctuation en python peut-être un avantage.
Merci pour cet article et le reste du magazine.
[^] # Re: Critique
Posté par GeneralZod . Évalué à 7.
C'est probablement plus par manque de place qu'autre chose que l'auteur n'a pas donné plus d'exemple. Par expérience, à moins de faire son ciol, un programme Python est souvent plus concis qu'un programme C, C++ ou Java mais rarement plus verbeux.
> Exemple n°3 (...)
J'ai l'impression que tu confonds C et C++.
Bien sûr que tu peux bricoler des boucles foreach en C (la GLib en fournit pour les tables de hachage par exemple), ou en C++. D'ailleurs, pas la peine de chercher dans Qt, la STL fournit un algorithme for_each, et Boost fournit une construction encore plus sophistiquée.
La différence c'est que la boucle "for x in tartampion" est une construction native du langage.
Un exemple de lecture de fichier lignes par lignes avec gestion d'exception en Java:
try {
BufferedReader br = new BufferedReader(new FileReader("machin.txt"));
while ((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
}
en python 2.6 (possible en 2.5 en important du futur with_statement) , ça donne;
with open("data.txt", 'r') as f:
for line in f:
print(line)
Python est plus concis et va à l'essentiel, ça n'enlève rien aux qualités du C++, de Qt et de Java mais c'est un fait. Et là ou je rejoins l'auteur de l'article, c'est que pour une initiation à la programmation, c'est nettement plus adapté que C++ ou Java. Les étudiants arrivent à un résultat plus gratifiant dans le même laps de temps ce qui est non négligeable.
[^] # Re: Critique
Posté par Kangs . Évalué à 2.
Parce qu'à la première lecture j'ai des doutes sur ton impartialité. Comment python gère les exceptions en 2 lignes m'aiderait sans doute à comprendre l'intérêt de ton exemple sans arrières pensées ;)
[^] # Re: Critique
Posté par GeneralZod . Évalué à 2.
ben, ça donne la même chose, puisque with permet de simplifier la gestion des exceptions.
Si tu veux la même chose avec try/finally:
f = open("data.txt", 'r')
try:
--for line in f:
----print(line)
finally:
--f.close()
ça reste un poil plus court, et dans les 2 cas en Python, mon fichier est fermé en cas d'erreur, ce que je n'ai pas fait en Java.
http://www.python.org/dev/peps/pep-0343/
[^] # Re: Critique
Posté par Bozo_le_clown . Évalué à 1.
Je croyais que c'était python qui avait un gestion bancale des exceptions jusqu' à la 2.5 . On ne disposait que d'un try.. except ou un try.. finally ce qui obligeait à imbriquer 2 blocs try pour obtenir la même chose que try..catch..finally.
Python s'est inspiré de Java sur ce coup là
http://docs.python.org/whatsnew/2.5.html#pep-341
[^] # Re: Critique
Posté par GeneralZod . Évalué à 2.
J'ai dis ça où ? nulle part.
J'ai juste dit que je n'ai pas rajouté la gestion de la fermeture de fichier dans le code Java.
> Je croyais que c'était python qui avait un gestion bancale des exceptions jusqu' à la 2.5
Oui, et ? Python 2.5 est sorti en 2006 (avec with en preview).
Sinon, Python 2.6 introduit une gestion des exceptions encore plus élégante avec with.
> ce qui obligeait à imbriquer 2 blocs try pour obtenir la même chose que try..catch..finally.
Pour dans le cas en question, Java t'impose d'imbriquer 2 blocs try (ou de renvoyer une exception), le premier pour gérer l'exception à l'ouverture du fichier, et un second pour fermer le fichier en cas d'erreur de lecture.
Donc mauvais exemple, sinon les constructions try/except/else ou try/finally suffisait pour la plupart des besoins. Je reconnais que quand on avait besoin d'une structure type try/catch/finally, c'était lourdingue d'où l'unification sous Python 2.5.
Même si traiter les exceptions est une bonne chose, Python ne te force pas à le faire, parfois, ça devient très vite lourdingue en Java. Je trouve with est une solution relativement élégante, un peu à la manière de l'idiome RAII en C++ (dont il s'inspire).
Et on pourrait arrêter cette gueguerre Java/Python ? Je ne vois en quoi dire que Python est plus concis que C, C++ ou Java reviendrait à dénigrer ces langages.
[^] # Re: Critique
Posté par phoenix (site web personnel) . Évalué à 2.
[^] # Re: Critique
Posté par phoenix (site web personnel) . Évalué à 1.
Pour la lecture du fichier, en Qt, la construction est légèrement plus compliqué car il faut passé par un QTextStream (ce qui n'ajoute qu'une ligne). Ce qu'il me manquait peut-être dans ce paragraphe c'était un exemple (que tu viens de donner) pour voir en quoi c'était plus simple.
Mise à part l'indentation, il est fortement possible que ce soit un langage plus rapide à apprendre (je ne suis pas sur que beaucoup d'étudiant pense a indenter dés le début correctement).
[^] # Re: Critique
Posté par Larry Cow . Évalué à 4.
Légère petite ellipse de rien du tout ;)
[^] # Re: Critique
Posté par Larry Cow . Évalué à 5.
Je sais pas, moi. Trouve un contre-exemple, un truc pour lequel le C est moins verbeux que son équivalent Python. Et si possible un truc pertinent pour un débutant (i.e. tu peux déjà oublier l'inlining d'assembleur, si c'est à ça que tu pensais).
J'utilise le toolkit Qt, (qui rajoute une surcouche au C++ mais cela reste du C++), et je peux très bien faire des foreach
En C++, oui. À condition de se cantonner à un toolkit donné (Qt, Visual, ...) , parce qu'il n'y a pas (encore?) de syntaxe standard pour ce genre de construction. En C, c'est niet.
Ton objection à son exemple se base sur une comparaison avec C++/Qt. Elle n'est pas fausse (ça permet effectivement de faire _beaucoup_ de choses de manière agréable), mais elle n'est pas très juste non plus : ce faisant, tu n'enseignes pas le C++ à tes élèves. Tu enseignes un "dialecte" bien spécifique du C++, incompatible avec d'autres implémentations. Et ça, c'est à peu près aussi critiquable que de leur apprendre à "faire du Borland" ou du Visual (si ce n'est que Qt est libre).
En Python, tu n'as besoin de rien d'autre.
Enfin, juste pour rire, compare (mentalement, hein) le code nécessaire pour trier les lignes d'un fichier en Python, et le même Java ou en C++ (avec Qt si tu y tiens). Rappel : en Python c'est globalement
f = open('monfichier','r')
print f.readlines().sort()
f.close()
(et encore, c'est parce que je n'ai pas le réflexe du 'with')
[^] # Re: Critique
Posté par beleys (site web personnel) . Évalué à 2.
J'ai peut être de très mauvais principe d'écriture ...
Mais je trouve que la lecture du contenu d'un fichier n'est pas très pratique du fait des variables non typées ...
Que leur portabilité est un désastre, je pense, dans l'écriture d'un code conséquent.
Par exemple, je code de la manière suivante :
Je code en ligne, puis, transforme en fonction ce qui peut l'être, en faisant un copié collé du code à mettre en fonction. Dans un cas, j'ai renommé mes paramètres afin d'avoir un nom plus général dans ma fonction ... hors je n'ai modifié que le nom dans l'intitulé de la fonction et pas dans son corps .... Et bien je m'en suis rendu compte deux jours plus tard ... quand j'ai mis ma fonction dans un module autre ... et qu'il n'arrivait pas à trouver ma variable.
La portabilité de celle-ci faisait qu'il prenait sans problème, une variable déclarée dans le corps du programme et non pas celle passée en paramètre (prise de tête garantie)
N'importe quelle compilateur m'aurait insulté copieusement dès le début :D
L'indentation est aussi affreuse, je n'aime pas du tout devoir remplacer les { } par des tabulations .. le copié collé de code est souvent affreux si l'on doit changer le niveau de tabulation
A part cela j'aime bien :D
Je ne suis pas encore très efficace avec ce langage (1,5 mois de pratique épisodique) mais j'arrive à en faire ce que je veux pour le moment
Et je plussois puissance beaucoup le système aide en ligne en ayant simplement à faire help(ma_fonction) dans un interpreteur
Le python, c'est bien, mangez en :D mais ce n'est pas ultime n'ont plus ...
Et je n'ose imaginé des débutants avec les problèmes des variables non typées et du code basé sur son indentation ...
++ Beleys
[^] # Re: Critique
Posté par Guillaum (site web personnel) . Évalué à 3.
La portabilité de celle-ci faisait qu'il prenait sans problème, une variable déclarée dans le corps du programme et non pas celle passée en paramètre (prise de tête garantie)
N'importe quelle compilateur m'aurait insulté copieusement dès le début :D »
Ce probleme est veridique, cependant :
1) Il existe des outils (pylint par exemple) qui font le genre de verifications qu'un compilateur pourrait faire, mais il est vrai, pas forcement avec l'efficacité d'un compilo du fait du coté dynamique.
2) Une fois les problemes de compilation passés, tu te rend compte qu'avec une bonne methodologie de test, tu evites beaucoup plus de problemes graves. Et la python est tres fort (c'est presque marrant d'ecrire des tests avec ;) (Je ne nie pas que les framework de tests existent dans d'autres langages, c'est juste plus lourd, je DETESTE tester du C, generalement je prefere le wrapper dans du python et tester le python...)
« L'indentation est aussi affreuse, je n'aime pas du tout devoir remplacer les { } par des tabulations .. le copié collé de code est souvent affreux si l'on doit changer le niveau de tabulation »
Ca c'est le boulot de ton editeur de texte. Personellement, (sachant que je Dev principalement avec le couple python/C et des fois en C++), je fais toujours beaucoup d'oublis de parentheses ou points virgules, par contre je n'ai JAMAIS eu de probleme d'indentation en python.
« Et je plussois puissance beaucoup le système aide en ligne en ayant simplement à faire help(ma_fonction) dans un interpreteur »
C'est marrant, c'est vraiment pour moi une des faiblesse de python et des langages dynamique, ton IDE a beaucoup de mal a t'afficher la doc d'une fonction ;) Pour cela je prefere vraiment le C/C++/Java/C# qui me permettent d'avoir sans soucis la doc et l'autocompletion de mes fonctions tres rapidement.
« Et je n'ose imaginé des débutants avec les problèmes des variables non typées et du code basé sur son indentation ... »
Et les debutants avec des SegFault ? Et pas les gentils segfault, je parles des mechantes qui n'arrivent qu'une fois sur deux ;) Quand tu vois que 90% des etudiants d'une celebre ecole d'ingenieur en informatique que je ne citerais pas ne savent pas ce qu'est un debuggeur, un debutant le sait encore moins, alors il ira chercher son segfault a coup de printf et il va ramer longtemps, quand il ne vas pas juste rester totalement bloqué (Je ne nie pas que certains traceback de python son flous, mais pas autant qu'(un/une) (beau/belle) Segfault ;)
[^] # Re: Critique
Posté par Romeo . Évalué à 1.
En toute logique ton code C est déjà indenté hein :)
[^] # Re: Critique
Posté par beleys (site web personnel) . Évalué à 2.
Dans tous les cas, j'utilise emacs comme IDE (on va dire que c'est presque une IDE :D )
Et bien, dans le cas d'un code classique, si je perds mon indentation à la suite d'une mauvaise manip (Copie-Colle, deplacement, factorisation de code) ...
Je reprend mon bloc et je fais une ré-indentation automatique du tout ...
Et bien en python, c'est pas cà, il faut tout se relire, revérifier que les indentations soient les bonnes (splendide quand on enchaîne les boucles imbriquées ... )
Apres, pour les SEGFAULT des débutants avec les langages classiques, ils peuvent être très facilement éviter par l'utilisation de bibliothèques pour la gestion des tableaux dans un premier temps par exemple ...
Il restera toujours le pointage en dehors du tableau lors de la recherche d'un élément ...
Mais là, Python a le même problème.
Après j'ai déjà encadré des étudiants en info ... comment dire ... L'indentation c'est pas leur fort dans une majorité des cas ... Mais bon, d'un autre coté, puisque là c'est obligatoire ... cela coincerait au début seulement :D à force ils seraient obliger de s'y mettre
++ Beleys
[^] # Re: Critique
Posté par Rork . Évalué à 1.
C'est peut être là qu'est le soucis, non? ;)
[^] # Re: Critique
Posté par yellowiscool . Évalué à 6.
Envoyé depuis mon lapin.
[^] # Re: Critique
Posté par Rork . Évalué à 3.
Peut être remplacé par une jolie récursivité. Faut dire qu'avec Python, je code au maximum en fonctionnelle.
De toute façon, dès que j'ai la moindre imbrication de if, while ou for, je me penche toujours dessus pour simplifier le code.
[^] # Re: Critique
Posté par yellowiscool . Évalué à 4.
Trop de récursivité tue la récursivité ©
Envoyé depuis mon lapin.
[^] # Re: Critique
Posté par Archibald (site web personnel) . Évalué à 5.
[^] # Re: Critique
Posté par Guillaum (site web personnel) . Évalué à 2.
Je reprend mon bloc et je fais une ré-indentation automatique du tout ...
Et bien en python, c'est pas cà, il faut tout se relire, revérifier que les indentations soient les bonnes (splendide quand on enchaîne les boucles imbriquées ... ) »
En etant de mauvaise foi, je dirais "Le HTML c'est vraiment mieux que le XHTML. Imagine, quand tu fais un copier-coller de code et que celui-ci ne marche pas et que des balises disparaissent pendant le traitement, le HTML peut encore entre analysé alors que le XHTML va forcement planter."
Pour rire, j'invite tous les gens qui font du python a ajouter un marqueur de fin d'indentation :
if toto:
while titi:
blo
#endwhile
#endif
Et comme cela, plus de probleme.
La je suis de mauvaise foi, mais c'est vrai qu'en pratique, je passe plus de temps a chercher des oublis d'accolades ou de points-virgules qu'a reindenter du code python. J'ai un tres bon editeur qui prend en compte l'indentation lorsque je copie colle du texte, et hop c'est bon. Il suffit d'un peu de rigeur lorsque l'on copie-colle et le probleme est reglé.
Reste tout de meme le probleme des tabs ou des espaces pour l'indentation, et CA c'est vraiment un probleme et je regrete que le langage ne soit pas plus strict a ce sujet.
« Apres, pour les SEGFAULT des débutants avec les langages classiques, ils peuvent être très facilement éviter par l'utilisation de bibliothèques pour la gestion des tableaux dans un premier temps par exemple ...
Il restera toujours le pointage en dehors du tableau lors de la recherche d'un élément ...
Mais là, Python a le même problème. »
Python te crache une exception avec le numero de ligne, une explication et des informations utiles.
C te fais un "Segfault". Si tu sais utiliser un debugger, tu peut trouver la ligne qui ne vas pas. Mais ce n'est PAS forcement elle qui pose probleme, des fois c'est quelque chose qui n'a totalement rien a voir. D'autres fois, le code marchait tres bien car l'on pointait en dehors du tableau dans une zone "sans danger" et du jour au lendemain cela ne marche plus (changement de compilateur, changement des indices ce qui fait que tu tapes maintenant bien en dehors de la memoire allouée. Bref c'est complexe.
C++ a le meme probleme, c'est moins le cas pour Java et C#, j'avoue.
Si on revient sur les erreurs que peuvent te donner le compilateur, je deteste C++ pour deux raisons, la premiere etant les erreurs que te crache GCC lorsque sur des fonctions templatées, c'est illisibles ;) La seconde raison c'est que pour GCC "Explicite is better...".
« Après j'ai déjà encadré des étudiants en info ... comment dire ... L'indentation c'est pas leur fort dans une majorité des cas ... Mais bon, d'un autre coté, puisque là c'est obligatoire ... cela coincerait au début seulement :D à force ils seraient obliger de s'y mettre »
J'ai aussi encadré des etudiants en info, et je t'avoue que pour la pluspart l'utilisation de python (apres avoir fait du C/Java/Pascal) etait un bonheur. J'ai meme eu une remarque "Avec python, c'est cool, il n'y a plus besoin d'indenter" d'un eleve qui voyait l'indentation comme le truc inutile que les profs demandent. Pour python, il n'indentait pas, il creent des sous-blocs logique.
Je me rappel aussi des heures de debogage dues a un ';' en trop sur la ligne du while ou du for. La personne qui s'est deja faite avoir connait le truc, et encore, mais je te garantie qu'il y a en chaque année qui pleurent a cause de ca ;(
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Critique
Posté par beb . Évalué à 2.
[^] # Re: Critique
Posté par Yth (Mastodon) . Évalué à 5.
Le C a un statut très particulier parmi les langages : tu es seul maitre à bord, tes conneries sont les tiennes, mais tes bidouilles aussi.
Ce n'est pas forcément le pied quand on veut un projet complexe, avec de multiples contributeurs de niveaux inégaux, et qu'on n'a pas le temps ou l'énergie de gérer le projet aussi bien que par exemple un kernel Linux, mais cette liberté est irremplaçable quand on en a besoin.
Personnellement, j'adore cette sensation de liberté quand je code en C :)
Et j'adore cette sensation de simplicité quand je code en Python.
Mais ce n'est pas pour les même choses...
Yth.
[^] # Re: Critique
Posté par Christophe Simonis (site web personnel, Mastodon) . Évalué à 1.
while stack: #{ o = stack.pop() if o: #{ process(o) #} else: #{ print("rien à faire") #} #}[^] # Re: Critique
Posté par Nim . Évalué à 4.
Les variables sont typées en python.
type(ma_variable) te renvoie toujours quelque chose et a + b échoue si a est un entier et b un chaine de caractère.
Le seul truc est que le typage est dynamique.
En effet lorsque l'on fait a = 5, python comprends tout seul que a est entier.
Et oui c'est important de le comprendre et de le dire à des débutants.
Pour avoir un peu présenté python à des débutants en programmation, ce n'est pas là dessus qu'ils avaient des soucis.
[^] # Re: Critique
Posté par jiyuu . Évalué à 3.
[^] # Re: Critique
Posté par Jean B . Évalué à 5.
Un nom n'est pas typé il sert juste a désigner un objet qui lui a un type/ une classe.
[^] # Re: Critique
Posté par Bozo_le_clown . Évalué à 1.
Tu enseignes un "dialecte" bien spécifique du C++, incompatible avec d'autres implémentations. Et ça, c'est à peu près aussi critiquable que de leur apprendre à "faire du Borland" ou du Visual (si ce n'est que Qt est libre).
Ah oui c'est vrai que python échappe à la règle. Pourtant à chaque fois qu'on pointe les défauts de son implémentation de référence on ne manque pas de nous rétorquer qu'il existe des implémentations qui pallie ces défauts.
Et pourtant :
http://jython.sourceforge.net/docs/differences.html
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Diff(...)
J'admets cependant que les écarts sont moindres mais en même temps comparer une lib qui contient un toolkit graphique et un langage me parait quelque peu orienté
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Critique
Posté par Larry Cow . Évalué à 7.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Bah tiens, une bonne raison d'utiliser Python : en Python pas besoin de mettre de bouchon pour indiquer qu'on a fini de lister les arguments. J'adore les fonctions qui acceptent un nombre illimité d'arguments « def f(*args): ... » ! De plus, le code bogué va provoquer un méchante erreur de segmentation alors que Python lève un exception qu'on peut attraper et traiter si on oublie un argument.
[^] # Re: Critique
Posté par パパフラクス . Évalué à 2.
[^] # Re: Critique
Posté par windu.2b . Évalué à 2.
Pour les windows, par contre...
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . Évalué à 2.
print ''.join(sorted(open('/etc/passwd').readlines()))C :
#include <unistd.h>int main() { (void)execl("/usr/bin/sort", "/usr/bin/sort", "monfichier", NULL); return 1; }
Bien que le code C utilise le programme externe sort, il est quand même plus long :-) (deux fois plus de lignes !)
Et le mix ?
#include <unistd.h>int main() { (void)execl("/usr/bin/python", "/usr/bin/python", "-c", "print ''.join(sorted(open('/etc/passwd').readlines()))", NULL); return 1; }
Bon ok, j'arrête.
[^] # Re: Critique
Posté par yellowiscool . Évalué à 3.
$ sort monfichier
Envoyé depuis mon lapin.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . Évalué à 2.
J'ai écrit un bref comparatif Python/C++ et Python/Java avec un exemple un peu plus élaboré que print "Hello" :
http://www.haypocalc.com/wiki/Python_ou_rien#Comparatif_avec(...)
Je rajouterai :
* C++ est trop long à compiler (la précompilation des entêtes aide un peu)
* C++ manque de modules standards, bien qu'il existe de grosses bibliothèques très utiles, portables et libres (ex: Qt, Boost)
Il y a aussi une différence importante sur la manière de concevoir les API. En C++ et Java, on adore mettre des const, static, private, etc. partout en obligeant l'utilisateur de l'API à passer par des méthodes. C'est utilisé pour qu'un utilisateur n'ait pas à se soucier de l'implémentation mais aussi pour éviter qu'il fasse n'importe quoi !
En Python, on a plus tendance à ne rien cacher et autoriser à tout modifier n'importe comment (cathédrale vs bazar ?). Bizzarement, ça marche : les projets Python restent lisibles et maintenables.
[^] # Re: Critique
Posté par yellowiscool . Évalué à 3.
C'est pas la même utilité.
Envoyé depuis mon lapin.
[^] # Re: Critique
Posté par vincent_k (site web personnel) . Évalué à 0.
[^] # Re: Critique
Posté par Bozo_le_clown . Évalué à 3.
[^] # Re: Critique
Posté par Antoine . Évalué à 2.
[^] # Re: Critique
Posté par ckyl . Évalué à 6.
server = imaplib.IMAP4(host)
server.login(user, passwd)
inbox = server.select()
typ, data = server.search(None, 'UNSEEN')
urls = []
for num in data[0].split():
typ, data = server.fetch(num, '(RFC822)')
for line in data[0][1].split("\r\n"):
# header & body part
(junk, sep, url) = line.partition("magic_key:")
if not url is "":
urls.append(url)
return urls
C'est sur ca fait facilement 5x moins de ligne que son équivalent en javamail. Par contre on peut le voir, c'est tout aussi pénible à utiliser. Je préfère écrire 5x plus de lignes, mais manipuler des abstractions et que je sache ce que je manipule. Je m'explique:
typ, data = server.search(None, 'UNSEEN')Qu'est ce que peut bien me retourner server.search ? Allons voir la doc: Search mailbox for matching messages. charset may be None, in which case no "CHARSET" will be specified in the request to the server. The IMAP protocol requires that at least one criterion be specified; an exception will be raised when the server returns an error. . Je suis bien avancé aucune idée de ce que peuvent être typ ou data. Moi je voulais manipuler une liste de message non lu. Il me retourne une structure dont je ne sais rien...
En "printant" la structure on découvre ce qui nous intéresse. C'est super pro comme démarche... On découvre qu'il "suffit" de faire un
data[0].split()pour avoir tout les ID des messages. Bon si ils changent la map dans une prochaine release tout va péter silencieusement mais c'est une autre histoire.Après on veut manipuler les messages. Rebelote on va voir la doc Fetch (parts of) messages. message_parts should be a string of message part names enclosed within parentheses, eg: ""(UID BODY[TEXT])"". Returned data are tuples of message part envelope and data.
Encore une fois aucune abstraction, on me balance un tuple dont l'un des éléments est le message sous forme d'une string. C'est un peu plus précis mais pas trop quand même. Et le message surtout je me démerde avec ma string hein.
Moi tout ce que je voulais c'est "Pour chaque message non lu chercher dans le corp du message les lignes contenant magic_key et en extraire la suite".
Le code python est peut être beaucoup plus court, mais a utiliser il est super pénible, casse gueule. Les notions d'objet et d'abstraction sont bien loin...
J'aime pas du tout l'API de javamail mais entre imaplib:
http://www.python.org/doc/2.5.2/lib/module-imaplib.html
http://www.python.org/doc/2.5.2/lib/imap4-objects.html
et javamail:
http://java.sun.com/products/javamail/javadocs/com/sun/mail/(...)
http://java.sun.com/products/javamail/javadocs/javax/mail/Fo(...)
http://java.sun.com/products/javamail/javadocs/javax/mail/Me(...)
je sais lequel est plus facile à manipuler et que c'est totalement indépendant de devoir écrire 50 lignes de plus...
[^] # Re: Critique
Posté par zul (site web personnel) . Évalué à 2.
#include
#include
#include
#include
class Personne {
std::string prenom, nom;
public:
Personne(const std::string &prenom_, const std::string &nom_): prenom(prenom_), nom(nom_) {};
friend std::ostream& operator<< (std::ostream&, const Personne&);
};
std::ostream& operator<< (std::ostream &os, const Personne &p) {
os << p.prenom << ' ' << p.nom;
return os;
}
void test() {
std::vector liste;
liste.push_back(Personne("Victor", "Stinner"));
liste.push_back(Personne("Damien", "Boucard"));
std::copy(liste.begin(),liste.end(),std::ostream_iterator(std::cout, "\n"));
}
Concernant le temps de compilation, bien sûr c'est long.Mais est-ce que c'est plus long que d'écrire un milliard de tests ou de planter après 2h d'éxécution pour pallier à l'absence de la phase de compilation (genre se tromper sur l'objet que tu passe à une méthode, détecter à 98% par le compilateur, jolie execption à l'éxecution sinon :)).
Autre point : tu t'appuye sur quels projets python de taille importante pour porter de tels jugements ? Quel intérêt de l'objet si tu n'utilise pas un minimum l'encapsulation ?
Pour information le mot clé const, ça indique un contrat fort, ne pas l'avoir c'est un manque assez désagréable. static ça ne réduit pas grand chose et des mécanismes similaires existent en python. private et protected, voir remarque plus haut.
[^] # Re: Critique
Posté par Guillaum (site web personnel) . Évalué à 3.
Bien que je sois d'accord sur ce probleme, je ne pense pas que la compilation puisse se passer de tests. Donc que l'on soit en python ou dans un autre langage, il faut faire des tests. Or un bon jeu de tests te procurera une couverture suffisante du code pour eviter les "plantages au bout de 2 heures".
« Autre point : tu t'appuye sur quels projets python de taille importante pour porter de tels jugements ? Quel intérêt de l'objet si tu n'utilise pas un minimum l'encapsulation ? »
Le probleme n'est pas de ne pas utiliser l'encapsulation, tu peux faire du code python tres proprement et en respectant une bonne demarche d'encapsulation. Le probleme ici est que l'encapsulation est une convention et non une regle du langage, libre a toi de l'utiliser ou pas.
En pratique, la convention python dit qu'il faut prefixer les privates par des _. A partir de ce moment la, quelqu'un qui utilise mon API peut se dire "ok, j'utilise un _, c'est mon choix, j'ai des raisons de le faire, mais je ne pleure pas si cela me pete a la geule" et un outil (genre pylint) peut faire des rapports de bonnes pratique et signaler les utilisations de variables "privée".
Maintenant, je dirais que chaque langage a sa specificité. J'ai cru mourir le jour ou j'ai fais du python avec des gens qui n'en avait rien a faire et qui attendait seulement que le projet se termine en pondant du code. A ces moment la c'est une horreur et je suis bien d'accord qu'un langage plus "strict" comme java sera mettre des gardes fou utiles.
En conclusion, si vous bossez avec des gens payés au lance-pierre et qui n'ont pas la volonté du travail bien fait (ni le temps d'ailleur), ne faite pas de Python, c'est des ennuis assuré. En Java par exemple, sauf grosse boulette, votre outil est certain de tourner pour la demo client ;)
Par contre, si vous chercher a faire du travail rapidement, de facon sympa, maintenable avec une super bonne demarche agile, essayez Python. Cela demande un peu de rigueur, des gens motivés et inteligents, mais cela vaut le coup.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Un mauvais programmeur arrivera toujours à écrire du code horrible... qu'importe le langage. Des fois, c'est à se demander s'il ne se donne pas du mal pour que le code soit incompréhensible et très difficilement maintenable :-)
J'ai déjà vu une réimplémentation de strcpy() dans un programme C++ (ce n'était pas une fonction, le code était recopié). Ou encore un classe dont le constructeur prenait 30 arguments (nommées a, b, c, ..., z, aa, ab, ... bien sûr) en C++. C'était un projet professionnel bien sûr :-) Ce n'est pas parce que le langage offre de super outils (ex: template, itérateurs, etc.) qu'ils vont être utilisés. Le problème est une mauvaise connaissance du langage, un manque d'expérience (apprentissage sur le tas) et toujours le manque de temps.
[^] # Re: Critique
Posté par zul (site web personnel) . Évalué à 2.
- typo dans le nom d'une variable qui sera "automatiquement" crée par python entrainant des résultats incohérents
- oubli dans une étape de refactoring qui enverra une jolie exception à l'execution
- envoi d'un objet invalide à une méthode entrainant une jolie exception (assez facile, quand on pousse le dynamisme loin).
Toutes ces choses peuvent donc être éviter dans un langage compilé / typé statiquement pour un coût nul. J'ai perdu assez de temps d'expérimentation à cause d'une erreur de ce genre dans des "use case" tordus quasi jamais utilisés (mes erreurs certes, mais un compilo les aurait remarqué :)) (pas en python, mais en ruby, un vrai langage objet (vendredi c'est permis)). C'est pour ça que je reste méfiant par rapport au temps gagné par la non-compilation. Jouer l'ensemble des jeux de tests (je parle même pas de l'écriture) est bien souvent plus long que la compilation elle-même.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . Évalué à 2.
C'est un faux problème. Effectivement, le compilateur C++/Java va refuser de compiler si on n'utilise pas les bons types. Par contre, les bugs « après 2h d'exécution » existent également en C++ et Java. Le compilateur n'est en rien une garantie que le programme ne va jamais planter. Les tests sont également nécessaires en C++ et Java pour garantir le bon fonctionnement du programme (on teste les cas qui marchent et on teste qu'une erreur est levée pour les cas invalides).
Je pense qu'un compilateur rassure les développeurs : si je me trompe, le compilateur va détecter mes erreurs. Or seuls un petit nombre d'erreurs sont détectées : les fuites de mémoire, lecture n'importe où en mémoire, faille de sécurité et autres ne sont pas détectées par le compilateur vu que les erreurs ne peuvent être détectées qu'à la compilation ou par une lecture attentive du code source.
L'absence de type est une force de Python : le duck typing permet d'écrire un algorithme générique à moindre frais : temps de compilation (en C++, il faut recompiler la fonction pour chaque combinaison de types) et code concis (pas besoin des horribles templates mégaverbeux de C++).
Note : pylint, pychecker et pyflakes comblent partiellement le manque de « compilateur » en Python (en réalité, Python est un compilateur : code source => bytecode Python). Python 3 autorise maintenant la déclaration des types mais ils ne sont pas validés, c'est juste informatif. Je pense qu'un drogué de C++/Java va écrire un outil pour valider les types ;-)
[^] # Re: Critique
Posté par Eric (EOL) LEBIGOT (site web personnel) . Évalué à 1.
# Quelques critiques d'un débutant
Posté par Pierre . Évalué à 2.
comment lancer le sel python ?
je n'ai pas trouvé dans la revue qu'il commencer le fichier par :
#! /usr/bin/pythonil y a peu être autre chose a utiliser ? mon programme ne risque t'il pas de ne pas fonctionner sur l'autre os avec ce genre linge ?J'essaye le programme pour afficher un ensemble de Mandelbrot (pages 29-30) mais si le calcul semble bien se passer , je n'ai aucun résultats à afficher ...
imshow(divergence, cmap=cm.spectral, extent=(-1, 1, -1, 1))où est-ce que je récupère ce résultat ?En bref le hors série donne envie de faire des choses mais pour un vrai débutant il reste un peu trop de recherches à faire de son coté pour pour se lancer dans la programmation en python avec le magazine comme seul support, ça ressemble plus à un comparatif de langage de programmation en faveur de python qu'à un ensemble d'article destiné à l'initiation du débutant.
[^] # Re: Quelques critiques d'un débutant
Posté par GeneralZod . Évalué à 2.
Mais l'article "Apprenez Python" comble en partie ce manque puisqu'il regorge de liens avec des bouquins (et de qualité pour la plupart) disponibles gratuitement.
Le (vrai|faux) débutant en Python a déjà un point de départ, et les autres articles pourront servir plus tard de référence. Après tout ce n'est qu'un magazine, le nombre de pages étant limité, c'est difficile de satisfaire tout le monde.
Le HS sur Ruby était plus accessible aux vrais débutants, mais mis à part l'article sur Rails et les gems, c'était un peu light pour un public plus avancé.
Sinon, pour afficher le résultat en question:
>>> from pylab import imshow, cm, show
>>> imshow(divergence, cmap=cm.spectral, extent=(-1, 1, -1, 1))
>>> show()
C'est un petit oubli de l'auteur, rien de bien méchant.
[^] # Re: Quelques critiques d'un débutant
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Pour débuter dans Python, je doute que numpy et scipy soient les modules les plus simples à apprendre :-) Python est quand même une super calculette, qu'autant qu'il a des nombres entiers de taille illimitée (limitée par la mémoire) et des nombres complexes ;-)
$ pythonPython 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> 1+1
2
Waouh ! Bon, voir le module math pour des trucs plus utiles ;-)
# En parlant de python
Posté par Romeo . Évalué à 1.
Quelqu'un voit de quoi je parle ?
[^] # Re: En parlant de python
Posté par Boa Treize (site web personnel) . Évalué à 3.
http://www.amazon.fr/grand-livre-Monty-Python/dp/2862746851
[^] # Re: En parlant de python
Posté par GeneralZod . Évalué à 2.
http://www.amazon.fr/Expert-Python-Programming-Tarek-Ziad%C3(...)
http://www.amazon.fr/Coeur-Python-Version-Vol-1-Nouveaux/dp/(...) (réédition du Vol 1. de Core Python, excellente introduction à Python 2.5 à lui seul).
[^] # Re: En parlant de python
Posté par Romeo . Évalué à 2.
# Python vs Perl
Posté par 6Ber Yeti . Évalué à 2.
D'abord, ceci n'est pas un troll.
Pour des tas de raisons, je me suis mis à Perl qui est devenu pour moi une vraie boîte à outils. Mais pas seulement. Ca m'a aussi servi à coder des utilitaires assez complets autour d'outils de gestion de conf / gestion des changements ...etc...
D'ailleurs, jusqu'à présent beaucoup de ces outils, en particulier propriétaires, offrent des API Perl mais pas (pas encore ?) Python.
Je ne connais rien de Python (OK, je devrais acheter le HS ...), mais en attendant, j'aimerai avoir votre avis sur la différence Perl / Python. Pourquoi préférer l'un plutôt que l'autre ?
Et n'oubliez pas, ceci n'est pas un troll ;)
[^] # Re: Python vs Perl
Posté par GeneralZod . Évalué à 3.
* syntaxe plus claire. Et quand tu dois relire 6 mois après ton propre code, ou bien reprendre celui de ton collègue, t'es bien content que ce soit du Python et non pas du Perl.
http://wiki.python.org/moin/PerlPhrasebook
Perl is worse than Python because people wanted it worse dixit Larry Wall himself.
* There's Not more than one way to do it
Python encourage les utilisateurs à adopter un style de programmation dit "pythonnique", un style concis, efficace et qui facilite la lecture du code source.
Perl, même avec les pragmas strict et warnings, reste trop laxiste.
Bien évidemment, on peut coder comme un porc sous Python et proprement sous Perl et vice-versa.
* support de l'OOP dans Perl c'est du bricolage. Perl supporte à peu près aussi bien l'OOP que le C ISO.
Bon, Python supporte 2 types de classes avec l'arrivée des classes "new style" dans Python 2.2, mais dans Python 3.x, toutes les classes sont "new style".
**troll**
* Plus rapide
http://shootout.alioth.debian.org/u32q/python.php
Pourquoi Perl:
* le traitement de données textuelles !
Le module re est un portage des regex Perl 5 mais depuis, ça n'a pas trop évolué. De plus, les regex ne sont pas partie intégrante du langage comme dans Perl.
Même si les piles incluses dans Python couvrent des domaines très large, qu'il existe des modules couvrant la plupart des besoins (calculs scientifiques, GUI, concurrence, etc...) et le PyPI (Python Package Index), on est encore loin de la richesse des modules offerts par CPAN.
Dans les grandes lignes c'est ça, après c'est également une question de point de vue. Ce qui est une qualité pour un développeur Perl peut être un défaut pour un développeur Python.
L'avis d'ESR si ça t'intéresse:
http://www.linuxjournal.com/article/3882
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.