Python 2.2.1 vient de sortir.
C'est surtout un paquet de bogues en moins, mais il y a quand même quelques nouvelles fonctionnalités, dont l'ajout plutôt controversé du type booléen.
Il est recommandé aux utilisateur de Python 2.2 de mettre leur version à jour.
C'est surtout un paquet de bogues en moins, mais il y a quand même quelques nouvelles fonctionnalités, dont l'ajout plutôt controversé du type booléen.
Il est recommandé aux utilisateur de Python 2.2 de mettre leur version à jour.
python 2.2.1 (818 hits)
les releases notes (379 hits)
le type booléen (516 hits)
> Lire la dépêche (23 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #107226.




Un petit mot
J'en profite au passage pour dire que Python est vraiment un langage incroyable. J'ai commencé que très réçemment et pourtant je l'ai assimilé très vite. Il permet de manipuler les objects avec une extrême souplesse et offre une très grande puissance.
Pour ceux qui ne connaissent pas encore Python, je vous encourage vivement à vous y plonger, ça vaut vraiment le coup, autant pour les admins que les développeurs.
[+] [^]Tout n'est pas si rose
J'ai lu un article dans 01 informatique disant que python n'arrivait pas à la cheville de perl, donc je suis plutot surpris par ton commentaire.
[^]Re: Tout n'est pas si rose
Moi j'ai lu sur le site msdn que rien ne valait vb .net...
[^]Re: Tout n'est pas si rose
[+1] pour la finesse du troll
[^]Re: Un petit mot
C'est ce que je pensais avant d'essayer Ruby :-).
[^]Re: Un petit mot
c'est encore ce que je pense apres avoir essayé ruby.
le 'more than one way to do it' j'accroche pas trop.
[^]Re: Un petit mot
le 'more than one way to do it' j'accroche pas trop.
Tiens, t'aimes pas unix ?
[^]Re: Un petit mot
si.
mais quand je tape mes commandes unix, je les tapes et c'est tout. Si j'étais sûr de ne jamais avoir a lire d'autres programmes que les miens, j'accrocherait peut-etre plus.
Quand au plus propre, meme si les itérateur c'est *vraiment* bien, ben bof.
exemple :
a = %w{kikoo les amis}
tu trouves ca intuitif, toi ?
et le fait de pouvoir mettre ou pas les parenthèses, les docstrings inexistantes, ...
bref, python.roxor_level == ruby.roxor_level and python.suxor_level < ruby.suxor_level
[^]Re: Un petit mot
a = %w{kikoo les amis}
C'est un shortcut, t'es pas obligé de l'utiliser...
et le fait de pouvoir mettre ou pas les parenthèses
Ça au contraire c'est génial, ça aère énormément le code.
les docstrings inexistantes
Si tu parles de la doc embarquée, elle y est. Si c'est spécifiquement d'un string qu'on met dans la définition d'une classe, il y a un exemple sur comment les ajouter dans le "pickaxe book". Et ça n'est pas ce genre de détail qui fait la différence sur la vitesse de développement.
[^]Re: Un petit mot
C'est un shortcut, t'es pas obligé de l'utiliser...
je sais bien, mais comme je l'ai dit plus haut : "Si j'étais sûr de ne jamais avoir a lire d'autres programmes que les miens, j'accrocherait peut-etre plus.".
Alors même si je l'utilise pas, je ne peux pas empecher tout le monde de l'utiliser. Du coup il faut quand meme en tenir compte, puisque je risque fort bien d'avoir a le lire. Et y'en a d'autres des comme ca.
Pour la doc, je parlais des docstrings, c'est a dire des commentaires associées aux modules, classes et methodes. Je crois pas que les commentaires ruby a la rdtool soit accessibles a l'execution.
Et même si ca accelere pas forcément, c'est bien pratique en cas de doute de taper lafonction.__doc__ dans un shell.
[^]Re: Un petit mot
Alors même si je l'utilise pas, je ne peux pas empecher tout le monde de l'utiliser.
A l'usage, je t'assure que ça n'est vraiment pas un problème pour la lisibilité.
Je crois pas que les commentaires ruby a la rdtool soit accessibles a l'execution.
Non, mais comme je te le disais c'est assez facile à ajouter. Je suppose qu'ils seront disponible en standard dans une version ultèrieure.
[^]Re: Un petit mot
ah un dernier truc qui me chiffone : la doc.
le seul truc dispo est le bouquin des 'pragmatic programmers' et la présentation de la bibliothèque standard est pas très pratique (rapport à java ou python)
et j'aime pas les 'inline regexp'.
Cela dit, je regarderai sans doute la prochaine version histoire de voir comment ca va evoluer.
[^]Re: Un petit mot
ah un dernier truc qui me chiffone : la doc.
Là c'est vrai, celle de Python est mieux foutue. Mais le "pickaxe book" (celui dont tu parles) est plutôt bien écrit, ça compense. Il y a aussi une quick ref dispo chez O'Reilly.
et j'aime pas les 'inline regexp'.
C'est pas important. La seule question au final c'est de savoir si ça t'aide ou pas pour écrire et relire du code. Et pour autant que j'ai pu le constater, ça aide.
[^]Re: Un petit mot
tiens, puisqu'on en est la, tu peux me dire la différence entre
3.times {
# machin
}
et
3.times do
# machin aussi
end
C'est une vrai question...
Et puis honnetement, les return implicite, ca sux
[^]Re: Un petit mot
do end et {} n'ont pas la même précédence :
http://www.rubycentral.com/book/language.html(...)
(recherche "Blocks, Closure, and Proc Objects")
Et puis honnetement, les return implicite, ca sux
cf. réponse sur les regexps inline :-).
[^]precedence
J'avais déja vu, mais c'est quoi ? La priorité des opérateurs dans la résolution des expressions, ou tout à fait autre chose ?
Parce que si c'est ça, pour une bête boucle, y'a pas vraiment de différence. Du coup, on va se retrouver avec les deux styles en fonctions des developpeurs. Pas terrible...
[^]Re: precedence
La priorité des opérateurs dans la résolution des expressions
Oui. C'est expliqué dans l'URL de mon post précédent.
Parce que si c'est ça, pour une bête boucle, y'a pas vraiment de différence.
Lis l'URL.
Sinon sur le plan style, en général on utilise {} pour les trucs très simple sur une ligne, et do end pour les blocs plus complexes.
[^]Re: Un petit mot
Bof. Ça te permet juste d'écrire un peu plus rapidement des scripts "jetables", et même dans ce cas la syntaxe est plus clean que celle de Python :-).
[^]Re: Un petit mot
Moi personellement entre Ruby et Python, j'hesite encore..
Ne serait-ce que parce qu'il y a beaucoup de code/developpeur qui connaisse Python que Ruby.
Je sais: si c'etait le seul argument alors il faudrait rester en shell/Tcl/Perl qui ont plus d'utilisateur, mais ces languages la je ne les apprecie pas DU TOUT..
[^]Re: Un petit mot
Quand on voit le nombre de projets sur Sourceforge c'est vrai que ça laisse rêveur.
Un truc chouette, le bouquin open de PyQT : http://www.opendocspublishing.com/pyqt/(...)
[^]Re: Un petit mot
Si tu dis ca, c'est que tu n'as pas encore essaye Ruby...
Ruby est bien plus puissant, d'ailleurs je devrais etre en train de bosser dessus plutot que de lire tes commentaires...
[^]Re: Un petit mot
Ruby est plus puissant, plus souple, mais moins lisible..
Python est plus lisible, personellement j'aime beaucoup la tabulation "significative": j'ai eu trop souvent a lire des fichiers mal indentes..
Mais trop verbeux: les self partout BEURK!
Guido aurait pu faire une exception et utiliser un $ ou un @ pour distinguer les variables des attributs et les methodes des fonctions..
Sinon en fait je trouve que les deux langages sont assez semblables..
[^]Re: Un petit mot
Ruby est plus puissant, plus souple, mais moins lisible [...]
Ah.
Python est plus lisible[...] Mais trop verbeux: les self partout BEURK!
Guido aurait pu faire une exception et utiliser un $ ou un @ pour distinguer les variables des attributs et les methodes des fonctions..
Justement, Ruby n'a pas besoin de 'self' partout, et '$' et '@' sont utilisés pour distinguer entre les variables globales et membres. C'est entre autre pour ça que finalement il est plus lisible que Python (les itérateurs ça aide beaucoup aussi, et ne pas avoir à mangler les noms de méthodes pour simuler le private/public également :-).