samedi 06 septembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

[42] Sortie d'Inkscape 0.40
[45] Tux Football
[50] Objecteering/UML 5.3.0 est sorti sous Linux x86
[56] Sendmail X : vers une réécriture majeure
[55] Duo: le jeu de Uno version libre et francophone
[20] Blender 2.35
[16] Sortie de DVDStyler v1.3 beta
[15] XdTV 2.0 est sorti
[25] Zope X3 en version finale
[2] Un nouveau logiciel de statistique pour KDE

Liens connexes

Nouveautés de la version 2.4 (2319 hits)
Téléchargement (1285 hits)
Nouveautés (long) (751 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Logiciel : Sortie de Python 2.4

Posté par Fabien (page perso, ). Modéré le 30 novembre 2004.

La version finale de Python 2.4 est sortie aujourd'hui le 30 novembre 2004. C'est une version finale et stable et il est recommandé aux utilisateurs de Python de se mettre à jour vers cette version.

Python 2.4 est le résultat de quasiment 18 mois de développements sur la base de la version 2.3 et représente une nouvelle étape dans l'évolution du langage. Les nouvelles fonctionnalités ont été gardées à leur strict minimum, des bogues ont été corrigés et des améliorations ont été apportées.

Les changements notables dans Python 2.4 incluent une amélioration de l'importation des modules, des décorateurs de fonctions/méthodes et des générateurs d'expressions.

Nouveautés de la version 2.4 (2319 hits)
Téléchargement (1285 hits)
Nouveautés (long) (751 hits)

> Lire les commentaires (77 commentaires, moyenne: 2,6).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] enfin....

Posté par Jean michel WILLI (page perso, ) le 30/11/2004 à 18:15. (lien). Évalué à -9.

une bonne nouvelle.

Décorateurs

Posté par paul brauner () le 30/11/2004 à 18:55. (lien). Évalué à 2.

Je trouve cette technique très élégante...est-ce que ça a été repompé à un autre langage ?

En tout cas, cela ajoute un certain contrôle des types dont l'abscence rebutait quelques uns

[^]Re: Décorateurs
Posté par Amand Tihon (page perso, ) le 30/11/2004 à 19:03. (lien). Évalué à 8.
Non, non. Enfin, ça permet plein de trucs, mais ça n'ajoute rien, à part un peu de sucre syntaxique. Ce n'est jamais que l'application d'une fonction "enrobante", ce qui était déjà possible. Avant, sans décorateurs:
```
class C:
    def m(x):
        pass
    m = staticmethod(m)
```
Maintenant, avec décorateurs:
```
class C:
    @staticmethod
    def m(x):
        pass
```
Évidemment, on peut (et on pouvait déjà, la syntaxe en moins) faire bien d'autres choses qu'un contrôle de type, avec les décorateurs. Voir http://www.python.org/moin/PythonDecoratorLibrary(...) pour quelques exemples.

[^]Re: Décorateurs

Posté par Romain Guy (page perso, ) le 30/11/2004 à 19:51. (lien). Évalué à 4.
Disons que ça ressemble beaucoup aux metadata de Java2 1.5 ^^ Du moins pour la syntaxe. J'ai regardé un peu comment utiliser les décorateurs et c'est vraiment sympa. On peut *enfin* déclarer des membres statique de manière lisible.

--
Romain GUY
http://jroller.com/page/gfx
http://www.progx.org
- [^]Re: Décorateurs
  
  Posté par Stéphane TRAUMAT (page perso, ) le 30/11/2004 à 20:33. (lien). Évalué à 4.
  Oui, en effet, cela ressemble au meta data de Java...
  On pouvait déja faire ça avec XDoclet. Cela permettait d'ajouter du code qui générait le source ou la config manquante.
  
  C'est très pratique !

[^]Re: Décorateurs

Posté par Nicolas Tramo () le 02/12/2004 à 12:51. (lien). Évalué à 1.
Le Décorateur est un design pattern assez ancien.

On peut l'utiliser dans tous les langages OO, mais j'ignore si d'autres langages l'utilisent directement.
Mais il me semble que java ainsi que .NET font une utilisation très poussée (parfois un peu trop) des design patterns de manière générale.
- [^]Re: Décorateurs
  
  Posté par Stéphane TRAUMAT (page perso, ) le 02/12/2004 à 13:06. (lien). Évalué à 2.
  Il est clair que la liste des patterns de theserverside par exemple est un peu trop importante... on peut s'en sortir très bien avec 5 ou 6 design patterns...
  - [^]Re: Décorateurs
    
    Posté par Sylvain Sauvage () le 02/12/2004 à 16:41. (lien). Évalué à 1.
    Le but des motifs de conception (ouaip, j'utilise un mot français, na) n'est pas d'être utilisés, c'est de servir.
    Mais effectivement, point trop n'en faut.
    - [^]Re: Décorateurs
      
      Posté par TImaniac (page perso, ) le 02/12/2004 à 17:34. (lien). Évalué à 3.
      Tant qu'à utiliser le terme français, autant utilisé le plus courament rencontré, cad Patron de Conception ;)
      Le but des dp est avant tout d'identifier et mettre un nom à un problème/solution : c'est un excellent moyen pour se faire comprendre d'autres développeurs sans avoir à réexpliquer comme fabriquer une roue.
      
      --
      MonoFrance
      - [^]Re: Décorateurs
        
        Posté par Sylvain Sauvage () le 02/12/2004 à 18:38. (lien). Évalué à 3.
        Ça y est, je le tiens mon troll ! ;o)
        Patron, c'est pas bien. Motif, c'est mieux.
        
        Je cite un de mes auteurs favoris (moi-même ;o) :
        
        Patron est en fait l'étymon de pattern, il a un sens très proche de gabarit, mais il a un second sens en français, celui de «dirigeant», qui peut créer une équivoque, une ambiguïté. Motif est la traduction usuelle de pattern en informatique : pour les expressions régulières, le traitement automatique de texte, etc.
        
        Motif porte à la fois le sens de figure, forme, répétée et celui de raison, motivation. Or l'utilisation du terme motif dans le contexte du génie logiciel ne permet pas de distinguer clairement laquelle des deux acceptions fait le plus de sens ; il est en effet autant probable que l'on parle de répétitions ou de formes abstraites, modèles de plusieurs formes concrètes, que de motivations, mobiles, d'utilisations de techniques, de concepts ou de modèles d'ingénierie.
        
        Toutefois, -- et contrairement à celui de patron --, le second sens de motif (raison, mobile) n'est pas antinomique de la définition de nos motifs : comme nous le verrons plus en profondeur, ceux-ci sont une motivation, une raison, de leur propre application et des concepts qu'ils véhiculent. Motif nous semble donc un meilleur choix comme équivalent {Ou un peu plus, grâce à la notion de motivation que le terme anglais ne porte pas.} du terme de pattern.
        
        [... ici figure une petite recherche sur google que je ne retape pas ...]
        
        Toutefois, l'on peut remarquer que l'utilisation de l'expression en anglais est fortement majoritaire ; la traduction n'est donc pas encore figée. C'est pourquoi nous avons décidé d'essayer de faire basculer l'usage vers l'utilisation de «motif de conception» comme traduction de design pattern.
        
        On n'utilise pas les motifs juste pour les utiliser mais parce qu'ils servent, ils sont motivés.
        
        [^]Re: Décorateurs
        
        Posté par Vivi (page perso, ) le 03/12/2004 à 10:52. (lien). Évalué à 3.
        pour les expressions régulières
        
        c'est "expression rationnelle" en français
        
        [^]Re: Décorateurs
        
        Posté par Sylvain Sauvage () le 03/12/2004 à 14:02. (lien). Évalué à 2.
        Damned ! Me suis fais eu :o)
        
        [^]Re: Décorateurs
        
        Posté par Gabriel () le 03/12/2004 à 11:05. (lien). Évalué à 2.
        Entre motif et patron je vote "motif" qui est plus proche du sens recherché.
        Et pourquoi pas : Modèle de conception.
        
        --
        Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
        
        [^]Re: Décorateurs
        
        Posté par Sylvain Sauvage () le 03/12/2004 à 14:05. (lien). Évalué à 2.
        Dans le texte original, j'avais aussi discuté modèle et gabarit mais modèle est vraiment utilisé à beaucoup trop de sauces. Quant à gabarit, c'est la traduction exacte de template (terme de construction navale : pièce de bois qui sert à en produire d'autres).
        
        [^]Re: Décorateurs
        
        Posté par TImaniac (page perso, ) le 03/12/2004 à 12:00. (lien). Évalué à 2.
        J'ai pris soin de préciser que Patron était la traduction la plus répendu et non la plus adéquate. Hors le but d'un DP est de communiquer un concept avec des termes que tous le monde utilise, donc même si ce n'est pas la meilleiur traduction, Patron de Conception reste le plus approprié à l'heure actuelle ;)
        
        --
        MonoFrance
        
        [^]Re: Décorateurs
        
        Posté par Sylvain Sauvage () le 03/12/2004 à 14:13. (lien). Évalué à 2.
        Oui mais non. Je n'ai pas remis les résultats de la recherche google parce qu'obsolètes maintenant (18 mois) mais on peut la refaire :
        
        recherche sur les pages francophones des chaînes (mots exacts, pluriel+singulier) :
        
        "patron(s) de conception" : 968+464
        "design pattern(s)" : 31100+7700
        
        Ok, ce n'est pas une recherche linguistiquement bien faite mais ça donne un aperçu : personne ne traduit (1 sur 27). Alors je m'accroche à faire changer ça pendant qu'il est encore temps.
        
        Allons-y Sancho. Sus aux géants !
        
        [^]Re: Décorateurs
        
        Posté par Éric (Jabber id, page perso, ) le 04/12/2004 à 15:34. (lien). Évalué à 0.
        > pour les expressions régulières,
        
        Tu veux dire les expression rationnelles ?
        (moi aussi je sais troller sur le français ;)
        
        [^]Re: Décorateurs
        
        Posté par Nicolas Tramo () le 06/12/2004 à 13:03. (lien). Évalué à 1.
        C'est ce genre de troll qui fait que tout le monde utilise les termes anglais.
        
        Au passage, un motif c'est un petit dessin.
        
        Modèle de conception si on veut bien faire comprendre que l'on vient de France, mais sinon, Design pattern me semble le plus approprié. (Cette dénomination ayant le même avantage que leur objectif : quand on dit design pattern, tout le monde sait de quoi on parle et on a pas besoin de réinventer la roue, alors que patron, motif, modèle de conception,... Faut chaque fois réexpliquer que l'on parle des design patterns)

le python c'est bon

Posté par Philippe Fremy (page perso, ) le 30/11/2004 à 18:55. (lien). Évalué à 6.

Bon, j'aime beaucoup ce langage. Simple, rapide a aprrendre, une lib de base tres tres complete permettant de faire a peu pres n'importe quoi.

Sa faiblesse vient a mon avis de son caractere hautement dynamique, qui l'autorise malheureusement a laisser des exceptions dans des coins tres sournois, qui ne seront peut-tres jamais mise en evidence durant les tests mais finiront par se lever en prod dans des condeitions bizarres.

Des outils comme pychecker ou peak aident a gerer ce genre de probleme mais je ne suis pas encore satisfait des limitations restantes.

Je reve d'un module qui aurait la force du compilateur de ocaml pour extraire l'ensemble des contraintes appliquees a chaque variable et qui en retirerait des erreurs, un peu comme ce qu'on a a la compile en C++.

--
phil.freehackers.org

[^]Re: le python c'est bon

Posté par Romain Guy (page perso, ) le 30/11/2004 à 19:53. (lien). Évalué à 4.
Là tu marques un point. Je fais encore des cauchemars en pensant à des erreurs levées pendant l'exécution du programme final parce que les tests n'avaient pas couvert 100% du code.

--
Romain GUY
http://jroller.com/page/gfx
http://www.progx.org
- [^]Re: le python c'est bon
  
  Posté par bobert () le 30/11/2004 à 21:27. (lien). Évalué à 1.
  Romain,
  ces erreurs aurait-elles pu être prévenues par des tests unitaires ? Peux-tu nous donner plus de précisions ?
  - [^]Re: le python c'est bon
    
    Posté par Amand Tihon (page perso, ) le 30/11/2004 à 23:44. (lien). Évalué à 6.
    ces erreurs aurait-elles pu être prévenues par des tests unitaires
    
    Pas toujours.
    En fait, à peu près tout est dynamique en python (les exceptions qui me viennent à l'esprit sont les types built-in).
    Ca veut dire que tu peux, durant l'exécution, ajouter ou retirer des méthodes à une instance, ou à une classe, tu peux modifier l'arbre d'héritage d'une classe, etc.
    
    Tout ceci signifie que l'interface de tes objets peut changer durant l'exécution, ce qui est parfois très pratique pour faire un système de plugins.
    
    Ajoute à ceci la possibilité de jouer avec les métaclasses (le type de ta classe, pas le type de ses instances), et un accès aux constructeurs eux-mêmes[1], et tu peux te retrouver devant de vrais casse-têtes.
    
    Je ne dis pas que c'est une bonne ou une mauvaise manière de programmer, juste qu'il y a beaucoup de champ libre et de possibilités de tester, dans un domaine qui est moins habituel quand on vient du java ou du C++.
    
    [1] Les méthodes appelées « constructeurs » en C++ ou java sont chargées d'initialiser l'instance (comme __init__ en python). Python remonte encore un cran plus haut et donne accès à la méthode qui retourne l'objet créé. Cela veut dire qu'on peut très bien avoir une classe C dont le constructeur (__new__) renvoie en fait une instance de D, même si C et D n'ont strictement rien en commun.
    - [^]Re: le python c'est bon
      
      Posté par TImaniac (page perso, ) le 01/12/2004 à 09:29. (lien). Évalué à 2.
      A vrai dire je me pose une question :
      Quel est l'intérêt de s'amuser à modifier une classe dynamiquement ? (cad d'y ajouter des attributs, des méthodes, etc.)
      Un exemple d'utilisation concrête ?
      
      --
      MonoFrance
      - [^]Re: le python c'est bon
        
        Posté par Tennis Prono (page perso, ) le 01/12/2004 à 09:49. (lien). Évalué à 4.
        Zope l'utilise pour ajouter à tout type d'objet des attributs de sécurité (pour savoir quel utilisateur peut ou pas appeler une méthode).
        
        --
        Pas de bureau 3d libre sans drivers libres!
      - [^]Re: le python c'est bon
        
        Posté par Philippe Fremy (page perso, ) le 01/12/2004 à 10:20. (lien). Évalué à 8.
        Tu peux faire des trucs du type:
        
        if KDE_SUPPORTED:
        XMainWindow = KMainWindow
        else:
        XMainWidow = QMainWindow
        
        class MyMainWindow( XMainWindow ):
        ....
        
        En fait, ces possibilites tres dynamiques ne sont pas tant un besoin qu'une possibilite naturelle offerte par le langage.
        
        Les methodes d'une classe sont stockees par exemple dans un dictionnaire attache a la classe, dictionnaire que tu peux manipuler a ta guise. Quel interet de les stocker dans un dictionnaire ? Il fallait bien les stocker quelque part. Quel interet de rendre le dictioninaire accessible ? Ben ca peut s'averer pratique dans certains cas mais Guido n'a pas vu de bonne raison de ne pas le faire.
        
        Par exemple, tu peux faire beaucoup d'introspection en python en passant justement par ce dictionnaire. Alors que en C++, c'est particulierement lourd a faire. Meme en Java ou en .NET, l'api d'introspection est beaucoup plus limitee.
        
        Les caracteristiques hautement dynamiques de python le rendent vraiment adapte pour faire des trucs un peu tordus ou des trucs complexes. Par exemple, la programmation oriente Aspect est hyper facile a mettre en place en python.
        
        Mais faut pas croire que parce que il y a des super fonctionnalites, on doit les utiliser. Perso, je n'utilise que les fonctionnalites de base, je me sert de python comme d'un C++ leger et rapide, avec beaucoup de types de bases tres elabores et une large bibliotheque de fonctions.
        
        --
        phil.freehackers.org
        
        [^]Re: le python c'est bon
        
        Posté par TImaniac (page perso, ) le 01/12/2004 à 10:48. (lien). Évalué à 2.
        Pour l'introspection je vois bien l'intérêt, pour la programmation orientée aspect aussi, même si dans la plupart des cas on cherche avant tout à générer du code "interne", non visible de l'extérieur, et donc pas des propriétés ou méthodes publiques.
        Mais le fait de pouvoir modifier une classe dynamiquement je ne vois toujours pas :) Quel intérêt y a t-il à tout à coup ajouter des méthodes à un objet, lui ajouter des propriétés ?
        Je comprends bien que le langage facilite ces manipulations mais quel est l'intérêt de pouvori le faire dynamiquement ? (vu tous les problèmes que celà semble poser)
        
        --
        MonoFrance
        
        [^]Re: le python c'est bon
        
        Posté par Antoine () le 01/12/2004 à 11:01. (lien). Évalué à 3.
        Mais le fait de pouvoir modifier une classe dynamiquement je ne vois toujours pas :) Quel intérêt y a t-il à tout à coup ajouter des méthodes à un objet, lui ajouter des propriétés ?
        
        Tu peux faire un proxy, par exemple pour appeler un objet distant en masquant l'API d'appel (XMLRPC, pipe, passage d'événement, etc.). Au premier appel d'une méthode, tu résouds l'appel à la main en générant l'appel vers un wrapper (qui est lui-même une fonction définie à la volée, en général une fermeture), mais au lieu de le regénérer à chaque fois, tu mets en cache le wrapper en question et l'ajoutes aux méthodes du proxy.
        
        [^]Re: le python c'est bon
        
        Posté par TImaniac (page perso, ) le 01/12/2004 à 11:50. (lien). Évalué à 2.
        Oué mais un wrapper ca se fait très bien statiquement...
        
        --
        MonoFrance
        
        [^]Re: le python c'est bon
        
        Posté par Antoine () le 01/12/2004 à 13:08. (lien). Évalué à 6.
        Oui, mais ça impose de prévoir toutes les méthodes à l'avance : et donc d'écrire une méthode wrappeuse par méthode wrappée.
        
        En Python tu peux détecter les appels de méthode inexistantes et créer la méthode wrappante correspondante à la volée. Ainsi ton proxy fait dix lignes une fois pour toutes au lieu de grandir à chaque nouvelle méthode de l'objet proxyisé. Le bénéfice en souplesse est inestimable.
        
        [^]Re: le python c'est bon
        
        Posté par spart (page perso, ) le 01/12/2004 à 18:54. (lien). Évalué à 3.
        c'est d'ailleurs la méthode utilisée par les bindings Qt pour Perl et Ruby.
        Il y a un runtime commun en C++ qui wrappe toutes les méthodes, une interface de requete pour les atteindre, et de tout petits modules Perl et Ruby pour les conversions de types.
        Avec 13000 méthodes disponibles, 30000 si on wrappe aussi KDE, c'est beaucoup plus simple.
        
        [^]Re: le python c'est bon
        
        Posté par Erwan (page perso, ) le 01/12/2004 à 23:51. (lien). Évalué à 4.
        Le probleme c'est qui ce n'est plus dans l'esprit du langage cible. Par exemple, avoir a utiliser QString en Ruby alors qu'on a une classe String qui est parfaite, c'est pas genial.
        
        [^]Re: le python c'est bon
        
        Posté par spart (page perso, ) le 02/12/2004 à 16:22. (lien). Évalué à 3.
        meuh non, on ne wrappe pas _toutes_ les classes sans discernement.
        Celles qui ont des équivalents natifs Ruby/Perl sont marshallées comme telles (ex. QString <=> chaine native, QStringList <=> liste native de chaines natives, etc.).
        
        [^]Re: le python c'est bon
        
        Posté par Philippe Fremy (page perso, ) le 01/12/2004 à 19:50. (lien). Évalué à 1.
        
        Ca sert aussi dans le cas de test unitaires pour faire des objets moqueurs (www.easymock.org). Exemple: def my_communication_protocol( my_interface, data ): # call many methods of my_interface # depending on the execution of each of them, handle # the communication protocol # return the result
        Maintenant, comment on teste un bazar pareil ? J'ai justement eu le probleme recemment ou j'ai du ecrire exactement ce genre de code, une fois en C++ et une fois en python. En C++, j'ai du creer une interface generique, rajouter des methodes virtuelles, passer pas mal de temps a memoriser les echanges et pas mal de temps a tester mon objet de test. En python, c'est 10 fois plus simple. Tu passes un objet mock qui va enregistrer tous les appels qui seront faits sur ton interface et qui peut eventuellement retourner des donnees fictives. Exemple reel tire de mon code de test: # correct data, correct sw my_rd = Mock( { "exchangeApdu": data + sw, "powerOn": [0x3B, 0] } ) sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) my_rd.clearCalls() self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) allCalls = my_rd.getAllCalls() self.assertEquals( len(allCalls), 1 ) self.assertEquals( allCalls[0].params[0], cmd ) - my_rd est un objet fictif qui retournera data+sw a la methode exchangeApdu, et la liste [0x3B, 0x00] a la methode powerOn. - je le passe a ScriptPlayerBase en lieu et place d'un objet lecteur reel - j'appelle la methode send sur my_rd. Derriere mon dos, sp va appeler my_rd et recevoir les reponses qu'il attend - je verifie que la reponse est correct de send est correcte - ensuite, je liste tous les appels effectues sur my_rd et je verifie qu'ils sont bien ce qu'ils doivent etre. Les capacites dynamiques de python permettent de faire facilement ce genre de chose. Le code pour la classe Mock fait 80 lignes commentaires et documenation comprise. Pour faire le meme test en utilisant une methode a la EasyMock, on aurait: # correct data, correct sw my_rd = EasyMock() my_rd.record() my_rd.powerOn() my_rd.setReturn( [0x3B, 0 ] ) my_rd.exchangeApdu( cmd ) my_rd.setReturn( data+sw ) my_rd.replay() sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) # if something went wrong, an exception would have been raised Malheureusement, personne n'a encore ecrit d'easymock pour python. Mais ca doit bien demander une heure de travail a tout casser.
        
        --
        phil.freehackers.org
        
        [^]Re: le python c'est bon
        
        Posté par Philippe Fremy (page perso, ) le 01/12/2004 à 20:38. (lien). Évalué à 6.
        
        Chuis vert, j'ai passe 10 minutes a mettre ce post en forme et tout est nique parce que j'ai appuye sur le mauvais bouton au mauvais moment. Ca sert aussi dans le cas de test unitaires pour faire des objets moqueurs (www.easymock.org). Exemple: def my_communication_protocol( my_interface, data ): # call many methods of my_interface # depending on the execution of each of them, handle # the communication protocol # return the result Maintenant, comment on teste un bazar pareil ? J'ai justement eu le probleme recemment ou j'ai du ecrire exactement ce genre de code, une fois en C++ et une fois en python. En C++, j'ai du creer une interface generique, rajouter des methodes virtuelles, passer pas mal de temps a memoriser les echanges et pas mal de temps a tester mon objet de test. En python, c'est 10 fois plus simple. Tu passes un objet mock qui va enregistrer tous les appels qui seront faits sur ton interface et qui peut eventuellement retourner des donnees fictives. Exemple reel tire de mon code de test: # correct data, correct sw my_rd = Mock( { "exchangeApdu": data + sw, "powerOn": [0x3B, 0] } ) sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) my_rd.clearCalls() self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) allCalls = my_rd.getAllCalls() self.assertEquals( len(allCalls), 1 ) self.assertEquals( allCalls[0].params[0], cmd ) - my_rd est un objet fictif qui retournera data+sw a la methode exchangeApdu, et la liste [0x3B, 0x00] a la methode powerOn. - je le passe a ScriptPlayerBase en lieu et place d'un objet lecteur reel - j'appelle la methode send sur my_rd. Derriere mon dos, sp va appeler my_rd et recevoir les reponses qu'il attend - je verifie que la reponse est correct de send est correcte - ensuite, je liste tous les appels effectues sur my_rd et je verifie qu'ils sont bien ce qu'ils doivent etre. Les capacites dynamiques de python permettent de faire facilement ce genre de chose. Le code pour la classe Mock fait 80 lignes commentaires et documenation comprise. Pour faire le meme test en utilisant une methode a la EasyMock, on aurait: # correct data, correct sw my_rd = EasyMock() my_rd.record() my_rd.powerOn() my_rd.setReturn( [0x3B, 0 ] ) my_rd.exchangeApdu( cmd ) my_rd.setReturn( data+sw ) my_rd.replay() sp = ScriptPlayerBase( my_rd ) sp.setUnexpectedRaisesException( 0 ) self.assertEquals( sp.send( cmd, sw=sw ), data + sw ) # if something went wrong, an exception would have been raised Malheureusement, personne n'a encore ecrit d'easymock pour python. Mais ca doit bien demander une heure de travail a tout casser.
        
        --
        phil.freehackers.org
        
        [^]Re: le python c'est bon
        
        Posté par Boa Treize (page perso, ) le 01/12/2004 à 11:03. (lien). Évalué à 3.
        Hé bien comme indiqué plus haut, par exemple : Zope ajoute des méthodes (et des propriétés) en rapport avec la sécurité à la plupart des objets qui lui passent sous la main. Ça évite que les programmeurs aient à s'en soucier (ce sont souvent de simples utilisateurs dans le cas de Zope), et ça permet de systématiser la politique de sécurité.
        
        Par ailleurs, on peut s'en servir pour patcher des objets pas à jour : genre tu es sur un vieux Python, tu ajoutes la méthode qui manque. (Bon, ça reste pas très ordinaire, c'est sûr, mais j'ai vu faire.)
        
        [^]Re: le python c'est bon
        
        Posté par TImaniac (page perso, ) le 01/12/2004 à 11:53. (lien). Évalué à 1.
        Vi mais le fait d'ajouter des propriétés de sécurité me fait plutôt dire que celà vient combler une lacune de la plateforme, celà devrait être en natif... Si c'est pour étendre une classe avec des propriétés rien ne vaut les méta-données !
        
        genre tu es sur un vieux Python, tu ajoutes la méthode qui manque.
        Vi mais comme d'hab quel est l'intérêt de le faire dynamiquement plutôt que statiquement.
        
        --
        MonoFrance
        
        [^]Re: le python c'est bon
        
        Posté par Gabriel () le 01/12/2004 à 10:54. (lien). Évalué à 1.
        Just epour avoir une précision:
        Les methodes d'une classe sont stockees par exemple dans un dictionnaire attache a la classe
        C'est un dictionnaire natif ou c'est une customisation à faire a posteriori?
        
        Parce que si c'est simplement une possibilité de rajouter à chaque fois, dans un dictionnaire géré par le programme, les noms des méthodes - ça voudrait dire que c'est pas de l'introspection mais une façon d'accéder aux méthodes ; au lieu de chercher les dynamiquement (introspection) , sans a priori savoir quelles elles sont. ça ressemble plus à de l'orienté aspect - comme tu dis plus bas.
        
        --
        Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
        
        [^]Re: le python c'est bon
        
        Posté par Boa Treize (page perso, ) le 01/12/2004 à 11:13. (lien). Évalué à 4.
        Le dictionnaire est natif.
        
        >>> liste = [1, 2, 3]
        
        >>> dir(liste)
        ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delslice__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmul__', '__setattr__', '__setitem__', '__setslice__', '__str__', 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
        
        >>> liste.__add__
        <method-wrapper object at 0x403ee9ac>
        
        >>> dir(liste.__add__)
        ['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__']
        
        >>> # etc...
      - [^]Re: le python c'est bon
        
        Posté par Pinaraf (Jabber id, ) le 01/12/2004 à 16:07. (lien). Évalué à 1.
        Un truc concret ?
        Tu prends un parseur de docs XML (j'ai pas eu le temps de regarder ça en python) en DOM.
        Genre ce fichier XML :
        [racine]
        [test]
          [aa]
           Contenu
          [/aa]
        [test]
        [/racine]
        
        Avec la modif dynamique d'une classe, c'est très pratique à parser (style SimpleXml dans PHP5) :
        doc = XMLDoc ("fichier.xml")
        print "Le contenu est " + doc.racine.test.aa.get_content()
        
        D'accord, sans modif dynamique, c'est facile suffit de l'opérateur [] :
        print "Le contenu est " + doc["racine"]["test"]["aa"].get_content() # note : c'est de l'à peu près :p
        
        Ou mieux :
        print "Le contenu est " + doc.xpath_content ("/racine/test/aa/")
  - [^]Re: le python c'est bon
    
    Posté par Philippe Fremy (page perso, ) le 01/12/2004 à 10:26. (lien). Évalué à 2.
    C'est difficile de faire des tests unitaires qui couvrent tout. C'est tres tres facile de faire des tests unitaires en python mais sur mes programmes, malgre la palanquee de test, il y a toujours des cas non testes.
    
    On peut eventuellement utiliser des outils de couverture de code (valider que les tests unitaires exercent tous les chemins) mais je ne suis pas sur ca suffise.
    
    Typiquement, comme les type sont dynamiques, je me retrouve souvent a abuser un peu de ca, et ca peut faire mal:
    
    def f( a ):
    if not type(a) is type([]): a = [ a ]
    # now, treat a as a list
    
    def g( b ):
    if type(b) is type([]):
    for e in b:
    g(b)
    
    Dans ces deux cas, g et f acceptent deja deux types d'arguments (a noter pour les pythonistes que g peut s'ecrire plus simplement avec map).
    
    En fait, je pense que ce n'est pas un bon style de programmation parce que c'est un peu dangereux. C'est avec ce genre de connerie qu'on se retrouve avec des chemins d'execution hyper complexes et qu'on peut lever une exception au mauvais moment.
    
    --
    phil.freehackers.org
    - [^]Re: le python c'est bon
      Posté par Papey () le 01/12/2004 à 13:17. (lien). Évalué à 3.
      
      def f( a ):
      if not type(a) is type([]): a = [ a ]
      # now, treat a as a list
      
      En effet, ce genre de traitement est vraiment dangereux. Avec ce genre de "patchage d'arguments" tu n'as aucune idée de ce que fait exactement ton programme. Si par mégarde un argument mal formé parvient à ta fonction, le programme continue comme si de rien n'était et va provoquer une erreur peut-être à l'autre bout de ton code source (si tu as mis des patches de ce genre-là un peu partout). Bon courage pour trouver l'origine de l'erreur dans ce cas-là...

[^]Re: le python c'est bon

Posté par ArBaDaCarBa () le 30/11/2004 à 21:03. (lien). Évalué à 1.
> Des outils comme pychecker ou peak aident a gerer ce genre de probleme mais je ne suis pas encore satisfait des limitations restantes.

Je connais pychecker (http://pychecker.sourceforge.net/(...)) qui est vraiment excellent, mais pas peak. Est-ce que c'est ça: http://peak.telecommunity.com/(...) ?

[^]Re: le python c'est bon

Posté par Antoine () le 30/11/2004 à 23:42. (lien). Évalué à 4.
Si tu veux un langage avec une syntaxe similaire à Python, mais du typage statique contrôlé à la compilation, il y a Boo :
http://boo.codehaus.org/(...)

C'est basé sur .Net (tourne sous Mono), et semble relativement rapide.
- [^]Re: le python c'est bon
  
  Posté par ArBaDaCarBa () le 01/12/2004 à 14:50. (lien). Évalué à 1.
  Ça n'a pas l'air mal ça... mais je pense tout de même rester avec Python, je m'y suis bien habituer.
  Pour faire plaisir à RB (http://linuxfr.org/comments/504102.html#504102(...)), il n'y a plus à déclarer self dans les fonctions.

Maturité

Posté par Veiovis () le 30/11/2004 à 20:16. (lien). Évalué à 3.

Outre la sortie de la version, le peu de changements concernant le langage lui-même est une bonne nouvelle. Cela signifie que le langage a atteint une certaine maturité. Cela lui donne une forme de standard. Les gens devraient être moins réticents à l'utiliser et il est fort à parier que le Python va continuer de plus belle son expansion.

[^]Re: Maturité

Posté par ArBaDaCarBa () le 30/11/2004 à 20:57. (lien). Évalué à 4.
C'est un des énormes avantages de Python, le langage évolué tout en douceur. J'ai très rarement eu de problèmes en essayant de faire tourner un vieux code.
Je trouve en plus le principe des PEP vraiment excellent.
- [^]Re: Maturité
  
  Posté par Fabien (page perso, ) le 30/11/2004 à 20:59. (lien). Évalué à 2.
  On n'a aussi pas trop de problème à faire tourner des morceaux de code sur des anciennes version de Python. Par exemple même si l'on tombe sur un Python 1.5.2, pas mal de fonction reste disponible.
  - [^]Re: Maturité
    
    Posté par ArBaDaCarBa () le 30/11/2004 à 21:06. (lien). Évalué à 1.
    A part les 'list comprehension' (mutation de listes en Français ? http://fr.diveintopython.org/odbchelper_map.html(...)) que j'utilise tout le temps... oui.

Pourquoi tous ces self ?

Posté par RB () le 30/11/2004 à 21:09. (lien). Évalué à 2.

Pourquoi dans les méthode de classe doit on systématiquement indiquer un argument 'self' (ou avec un autre nom) qui représente l'instance alors que l'on pourrait avoir ce mot implicitement reservé à cet usage dans la classe ? C'est très lourd je trouve...

[^]Re: Pourquoi tous ces self ?

Posté par Nicolas Évrard (Jabber id, page perso, ) le 30/11/2004 à 21:44. (lien). Évalué à 6.
Cela fait partie du karma python:

Explicit is better than implicit

Grâce à cela tu sais automatiquement que self (que tu aurais pu appeler me) est l'instance qui possède la méthode.

Mais si tu veux tout savoir GvR y répond là:

http://mail.python.org/pipermail/tutor/2004-April/028999.html(...)

--
Le scheme c'est bien.
- [^]Re: Pourquoi tous ces self ?
  
  Posté par Gniarf () le 30/11/2004 à 22:27. (lien). Évalué à 4.
  > Cela fait partie du karma python:
  
  > Explicit is better than implicit
  
  ah, comme COBOL, quoi :)
  
  --
  Windows has no users. It has hostages.
  - [^]Re: Pourquoi tous ces self ?
    
    Posté par Amand Tihon (page perso, ) le 30/11/2004 à 23:15. (lien). Évalué à 2.
    > Explicit is better than implicit
    ah, comme COBOL, quoi :)
    
    Merci de ne pas confondre « explicite » et « verbeux » :-)
    - [^]Re: Pourquoi tous ces self ?
      
      Posté par lasher () le 30/11/2004 à 23:18. (lien). Évalué à 3.
      Tu veux dire comme Java ? :>

[^]Re: Pourquoi tous ces self ?

Posté par Ramso (page perso, ) le 30/11/2004 à 22:00. (lien). Évalué à 1.
« Explicit is better than implicit »

--
Groar !

[^]Re: Pourquoi tous ces self ?

Posté par reno () le 30/11/2004 à 22:59. (lien). Évalué à 0.
J'ai lu les commentaires "Explicit is better than implicit" mais je soupconne que c'est une justification 'a posteriori', cela reflete juste qu'historiquement au debut il n'y avait pas d'objet et cela a été rajouter ensuite..

Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language.

Bon, c'est comme tout, cela a des avantages et des inconvénients.

Le seul réel avantage que je connaisse , c'est pour appeler un attribut f sur une liste d'objets, on peut faire facilement un map( f , <liste d'objet>) mais au niveau cout visuel c'est quand même cher payé!
- [^]Re: Pourquoi tous ces self ?
  Posté par Nicolas Évrard (Jabber id, page perso, ) le 30/11/2004 à 23:29. (lien). Évalué à 3.
  
  J'ai lu les commentaires "Explicit is better than implicit" mais je soupconne que c'est une justification 'a posteriori', cela reflete juste qu'historiquement au debut il n'y avait pas d'objet et cela a été rajouter ensuite..
  
  C'est tout à fait ça. Guido l'explique dans le lien que je donne dans mon commentaire.
  
  Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language.
  
  Le fait de chercher à ne rien cacher de ce qu'il se passe est au contraire une grande force de python. D'ailleurs, les décorateurs sont un peu à côté de la plaque à ce niveau là, je ne trouve pas qu'ils soient franchement très parlant. Pas mal de syntaxes différentes ont été proposées et celle choisie n'est pas (à mon avis) la meilleure.
  
  J'aurai largement préférer un truc tel que
```
class A(object):

   memoize:

         def fact(...):

               .........

          def tralala(...):

                .........
```
  qui a l'avantage de ne pas introduire un nouveau symbole, de bien montrer la subordination des méthodes à un décorateur et qui n'oblige pas à répéter le même décorateur pour toutes les fonctions. Mais bon c'est GvR qui a le dernier mot et puis il faut voir à l'usage, peut-être que je préférerai ce choix là dans un an.
  
  --
  Le scheme c'est bien.
  - [^]Re: Pourquoi tous ces self ?
    
    Posté par reno () le 01/12/2004 à 08:41. (lien). Évalué à 2.
    >Le fait de chercher à ne rien cacher de ce qu'il se passe est au contraire une grande force de python.
    
    Oui, mais ce n'est pas appliqué partout autrement python serait de l'assembleur, un bon contre exemple est l'unification des int et des long int en python.. Pour l'appel de fonction, ce principe la aurait put s'appliquer ou pas, il l'a été mais bof..
    
    Pour ce qui est des décorateurs, j'avoue ne pas comprendre ce que c'est ni à quoi ça sert, quelqu'un aurait-il une URL qui explique cela de façon claire? J'ai déja essayer de lire le PEP, mais sans succes..
    - [^]Re: Pourquoi tous ces self ?
      
      Posté par Laurent Pointal (page perso, ) le 01/12/2004 à 09:16. (lien). Évalué à 3.
      Voir là:
      http://peak.telecommunity.com/DevCenter/VisitorRevisited(...)
      
      Et dans le PEP il ya a quand même quelques exemples:
      http://www.python.org/peps/pep-0318.html(...)
      
      A+
      
      Laurent.
      
      --
      (pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
- [^]Re: Pourquoi tous ces self ?
  
  Posté par Philippe Fremy (page perso, ) le 01/12/2004 à 10:33. (lien). Évalué à 3.
  << Le 'Explicit is better than implicit' est un argument creux: si c'était le cas, on programmerait toujours en assembleur: il n'y a pas plus explicite comme language. >>
  
  Au contraire, l'assembleur est plutot obscur comme langage. Python est d'une clarte limpide a la lecture et ca, ca vaut cher.
  
  J'avoue que ca me gonflait aussi un peu au debut, maintenant, je m'y suis fait meme si je l'oublie de temps en temps, ou si je le rajoute sur des fonctions qui n'en ont pas besoin.
  
  Note que ce n'est pas le seul langage qui demande a declarer explicitement l'instance de l'objet. C'est le cas aussi pour lua, il me semble que c'est aussi le cas pour javascript et je suis sur qu'on peut en exhiber un certtain nombre comme ca.
  
  --
  phil.freehackers.org
  - [^]Re: Pourquoi tous ces self ?
    
    Posté par reno () le 01/12/2004 à 19:00. (lien). Évalué à 3.
    >Au contraire, l'assembleur est plutot obscur comme langage.
    
    Tu confonds clareté et explicite/implicite: python est très simple à lire, très claire car il fait des tas d'opérations implicite derriere ton dos: conversion int<-> big_int, ramasse-miette, etc.. qui doivent être fait de maniere explicite en C ou en assembleur..
    
    Sinon pour le self explicite, c'est assez répandu effectivement sur tout les languages ou les objets ont été rajoutés apres, en surcouche..
    
    Et je trouve cela tres moche, d'ailleurs je me demande pourquoi ne pas tout simplement avoir 2 mots: def pour définir les methodes (sans le self) et fun pour définir les fonctions..
    - [^]Re: Pourquoi tous ces self ?
      
      Posté par Antoine () le 01/12/2004 à 20:47. (lien). Évalué à 6.
      Et je trouve cela tres moche, d'ailleurs je me demande pourquoi ne pas tout simplement avoir 2 mots: def pour définir les methodes (sans le self) et fun pour définir les fonctions..
      
      Parce qu'en Python, une méthode c'est simplement une fonction qui a été ajoutée comme attribut d'une classe ou d'un objet.
      
      Par exemple si j'ai une classe Carre:
      
      class Carre(object):
      def __init__(self, cote):
      self.cote = cote
      
      Je peux définir une fonction aire_carre pour calculer l'aire d'un carré :
      
      def aire_carre(carre):
      return carre.cote ** 2
      
      print aire_carre(Carre(5)) # affiche 25
      
      Et il suffit d'attacher cette fonction à la classe Carre pour en faire une méthode :
      
      Carre.aire = aire_carre
      print Carre(6).aire() # affiche 36

Et les perfs ?

Posté par Boa Treize (page perso, ) le 01/12/2004 à 10:45. (lien). Évalué à 4.

On dirait que tout le monde à zappé ça : Python 2.4 inclut un bon nombre d'améliorations des performances, détaillées dans l'indispensable http://python.org/dev/doc/devel/whatsnew/whatsnew24.html(...) (beaucoup plus digeste que NEWS.html). Voir notamment le paragraphe 11.1, en bas de http://python.org/dev/doc/devel/whatsnew/node12.html(...)

Environ 5% plus rapide que Python 2.3, et 35% plus rapide que Python 2.2. Quand même ! Bon, le benchmark utilisé est standard mais pas très représentatif, si vous avez d'autres chiffres, faites passer.

Je suis impressionné par le travail de Raymond Hettinger, qui me donne l'impression d'être l'accélérateur de Python.

[^]Re: Et les perfs ?

Posté par opq () le 01/12/2004 à 12:20. (lien). Évalué à 3.
Sauf qu'en général, il se fait taper dessus: ses "accélérations" sont (parfois) des hacks, certes très intelligent, mais qui rendent très complexe le code du langage.

De plus, ces hacks sont propre au CPython et pas toujours facile à rendre / à faire passer aux autres implèmentations (ironpython, jython)

Enfin, certains vont lui repprocher des accélérations aux détriments de la complexité du langage. (en terme d'utilisation, pas juste le code). Un exemple : le module dequeue pour faire des piles. C'est rapide, mais ca fait un type de base que personne ne va aller chercher, vu que tout le monde va passer par une liste.

--OPQ

Quel éditeur/IDE pour python ?

Posté par Thomas Carrié (page perso, ) le 01/12/2004 à 17:59. (lien). Évalué à 3.

Quel éditeur et IDE utilisez-vous pour Python ?

[^]Re: Quel éditeur/IDE pour python ?

Posté par Amand Tihon (page perso, ) le 01/12/2004 à 18:35. (lien). Évalué à 2.
Pour tester des très petits trucs rapidement : pas d'éditeur, juste le shell python.
Pour tester des trucs un peu plus gros, mcedit ou Kate, suivant l'inspiration et la phase de la lune.
Pour le "vrai" développement, Kate
- [^]Re: Quel éditeur/IDE pour python ?
  
  Posté par Nicolas () le 01/12/2004 à 18:48. (lien). Évalué à 4.
  pour les trucs rapide je conseillerai ipython plutot que le shell super limite de python.
  
  pour le ide il y en a plein: emacs, vim, kate, kdevelop, eric etc
  - [^]Re: Quel éditeur/IDE pour python ?
    
    Posté par ArBaDaCarBa () le 01/12/2004 à 19:33. (lien). Évalué à 2.
    ipython (http://ipython.scipy.org/(...)) a effectivement l'air très intéressant... je vais l'essayer, merci.
    
    Et sinon, est-ce que quelqu'un arrive à se servir de Leo (http://leo.sourceforge.net/(...)) ?
    - [^]Re: Quel éditeur/IDE pour python ?
      
      Posté par golum () le 02/12/2004 à 10:55. (lien). Évalué à 3.
      <_TROLL_>
      Leo , j'ai jamais réussi à m'en servir correctement car y'a toujours une incompatibilié avec la version de wxWidgets
      </_TROLL_>
      
      Si tu veux du portable basé sur wxWidgets et stable tu peux essayer
      SPE
      http://spe.pycs.net/(...)
      
      Pour faire des trucs simples, y'a rien de mieux que Scite
      J'aime bien aussi Drpython :
      http://drpython.sourceforge.net/(...)
      
      Sinon tu as aussi le plugin Eclipse qui bouge pas mal en ce moment
      http://pydev.sourceforge.net/(...)
      
      cf:
      http://c2.com/cgi/wiki?PythonPluginForEclipse(...)
      - [^]Re: Quel éditeur/IDE pour python ?
        
        Posté par golum () le 06/12/2004 à 20:34. (lien). Évalué à 2.
        Tutoriel SPE vu sur Daily Python URL
        
        http://www.serpia.com/spe_tutorial/spe_tutorial.htm(...)

[^]Re: Quel éditeur/IDE pour python ?

Posté par ArBaDaCarBa () le 01/12/2004 à 19:28. (lien). Évalué à 1.
Pour un tout petit changement, vim.
Pour un plus gros travail emacs, car *par défaut* il insère des espaces au lieu de tabulations...
Bicycle Repair Man (http://bicyclerepair.sourceforge.net/(...)) n'est pas un IDE, mais c'est quand même très pratique à avoir.

[^]Re: Quel éditeur/IDE pour python ?

Posté par manatlan (Jabber id, page perso, ) le 01/12/2004 à 19:30. (lien). Évalué à 3.
SciTE, bien configuré pour le python ... est irremplaçable ... et multi plateforme et gpl

--
manatlan.com
- [^]Re: Quel éditeur/IDE pour python ?
  
  Posté par eJah () le 01/12/2004 à 20:43. (lien). Évalué à 2.
  D'ailleur si tu pouvais mettre ta config quelquepart ça m'interesserait au plus haut point.
  
  Merci :)

[^]Re: Quel éditeur/IDE pour python ?

Posté par paul brauner () le 01/12/2004 à 22:20. (lien). Évalué à 1.
Moi j'utilise l'éditeur fourni avec python la plupart du temps : IDLE

C'est du TK donc c'est pas super beau mais à part ça c'est très pratique et on sent que ça a été programmé par des gens qui utilisent bcp python (cad guido ici :)

C'est pas un super IDE avec 50 fonction intégrée mais il soutient largement la comparaison face à kate par exemple.

Sinon y'a eric3 qui est "le super IDE avec 50 fonctions intégrées"

Enfin, l'indétônable emacs gère très bien python

[^]Re: Quel éditeur/IDE pour python ?

Posté par Tennis Prono (page perso, ) le 02/12/2004 à 08:39. (lien). Évalué à 1.
Emacs et pythonwin.

--
Pas de bureau 3d libre sans drivers libres!

[^]Re: Quel éditeur/IDE pour python ?

Posté par syntaxerror () le 02/12/2004 à 11:07. (lien). Évalué à 3.
Souvent cité: Boa constructor http://boa-constructor.sourceforge.net/(...)

SPE à l'air pas mal du tout: http://spe.pycs.net/(...)

Spe is a python IDE with auto-indentation, auto completion, call tips, syntax coloring, syntax highlighting, class explorer, source index, auto todo list, sticky notes, integrated pycrust shell, python file browser, recent file browser, drag&drop, context help, ... Special is its blender support with a blender 3d object browser and its ability to run interactively inside blender. Spe ships with wxGlade (gui designer), PyChecker (source code doctor) and Kiki (regular expression console). Spe is extensible with wxGlade.

Mais bon, j'ai juste un peu joué avec. Pour ce que je fais, je reviens vite à emacs ou vi selon l'humeur ou l'environnement.
- [^]Re: Quel éditeur/IDE pour python ?
  
  Posté par Philippe Fremy (page perso, ) le 02/12/2004 à 20:17. (lien). Évalué à 2.
  Moi ce que je cherche, c'est vraiment un bon debuggeur python portable. Pour l'instant, j'ai que dalle. J"arrive pas a me faire a pdb et je n'ai pas trouve de debugger potable. Je compte essayer eclipse prochainement, j'espere qu'il s'en sortira bien...
  
  --
  phil.freehackers.org
  - [^]Re: Quel éditeur/IDE pour python ?
    
    Posté par golum () le 03/12/2004 à 13:46. (lien). Évalué à 4.
    T'as essayé PyDev le plugin Eclipse
    http://pydev.sourceforge.net/(...(...))
    
    Il semblerait que la dernière version en propose un, mais j'ai pas testé

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Sortie de Python 2.4

[+] enfin....

Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

[^]Re: Décorateurs

le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

[^]Re: le python c'est bon

Maturité

[^]Re: Maturité

[^]Re: Maturité

[^]Re: Maturité

Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

[^]Re: Pourquoi tous ces self ?

Et les perfs ?

[^]Re: Et les perfs ?

Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?

[^]Re: Quel éditeur/IDE pour python ?