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.
Aller plus loin
- python 2.2.1 (2 clics)
- les releases notes (3 clics)
- le type booléen (1 clic)
# Un petit mot
Posté par nemerid . Évalué à 10.
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
Posté par Annah C. Hue (site web personnel) . Évalué à -6.
[^] # Re: Tout n'est pas si rose
Posté par youpi_youpi . Évalué à 10.
[^] # Re: Tout n'est pas si rose
Posté par Frank-N-Furter . Évalué à 6.
Depending on the time of day, the French go either way.
[^] # Re: Un petit mot
Posté par Guillaume Laurent (site web personnel) . Évalué à 8.
[^] # Re: Un petit mot
Posté par lorill (site web personnel) . Évalué à 7.
le 'more than one way to do it' j'accroche pas trop.
[^] # Re: Un petit mot
Posté par Annah C. Hue (site web personnel) . Évalué à 2.
Tiens, t'aimes pas unix ?
[^] # Re: Un petit mot
Posté par lorill (site web personnel) . Évalué à 4.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
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
Posté par lorill (site web personnel) . Évalué à 6.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
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
Posté par lorill (site web personnel) . Évalué à 1.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
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
Posté par lorill (site web personnel) . Évalué à 1.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
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
Posté par lorill (site web personnel) . Évalué à 1.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Un petit mot
Posté par reno . Évalué à 1.
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
Posté par Lafrite . Évalué à 3.
Un truc chouette, le bouquin open de PyQT : http://www.opendocspublishing.com/pyqt/(...)
[^] # Re: Un petit mot
Posté par NeuCeu . Évalué à 0.
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
Posté par reno . Évalué à 1.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
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 :-).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.