Re: [SSFR] quel langage ?

[Sébastien Aperghis-Tramoni <maddingue@xxxxxxx>]

Selon Philippe Jacquot <philippe.j@xxxxxxxxx>:

> Bah, bon, soyons raisonnables, c'est surtout affaire de subjectivité
> tout ça. Perso, ce que je trouve séduisant dans Python, hormis
> l'orientation object du langage, c'est la souplesse des traitements de
> données, notament l'accès aux éléments de listes.
> [...]

Ca n'a rien d'innovant, ça ne résoud pas un problème qui serait
insoluble avec les autres langages, mais c'est mignon.
Ca doit bien permettre de gagner quelques caractères par rapport
à d'autres langages en remplaçant une syntaxe bizarre par une autre
syntaxe bizarre, un peu plus compacte.

> La gestion d'erreurs est aussi simplifiée avec les clauses try/except.
> Je connais pas trop C, mais j'imagine que ça marche pareil que catch.

C est un peu plus qu'un macro assembleur. La gestion d'erreurs est
donc quasi-inexistante nativement mais on peut en construire des
sophistiquées. La manière traditionnelle est de partir de setjmp() /
longjmp().

> L'indentation, on aime ou on aime pas, mais elle est significative en
> python. Attention aux editeurs de textes mal configurés..

C'est probablement la pire "fonctionnalité" de Python. La première fois
que j'ai entendu parler de ça, je n'y croyais pas, je ne pensais pas
que ce serait "mieux". Maintenant que je vois du code Python, j'en suis
convaincu : c'est une vraie mauvaise idée, qui rend le code moins lisible.
Les blocs deviennent moins visibles, leurs frontières naturelles ayant
disparues. Sur les longues boucles et fonctions imbriquées, on ne sait
rapidement plus à quel niveau on est.

> Support des fonctions lambda, équivalent des fonctions anonymes de perl.

Ne t'habitue pas trop à map(), filter() et reduce(); ces fonctions ont
été jugées trop lispiennes et seront sabrées de Python 3000.

    http://www.artima.com/weblogs/viewpost.jsp?thread=98196
    http://lambda-the-ultimate.org/node/view/587

> Maintenant, bon, je découvre aussi. Je suis en train de passer petit à
> petit mes moulinettes en Python, et je me rends compte que, non
> seulement ça facilite la lecture, mais en plus je peux mieux gérer des
> conditions d'exception qui étaient assez "lourdes" à traiter en Perl.

Pourtant le mécanisme de gestion d'erreurs de base est déjà bien
pratique et facile avec eval {} et test sur $@. Ou on peut utiliser
Exception::Class::TryCatch pour gérer ça de manière plus OO. Il y a
aussi Error::TryCatch.

    http://search.cpan.org/dist/Exception-Class-TryCatch/
    http://search.cpan.org/dist/Error-TryCatch/

La gestion des erreurs de Python est similaire à celle de Java, donc
elle est probablement agréable quand on aime ce système. Par contre,
je me permettrais de critiquer le mot clé "except" qui est encore une
mauvaise idée parce qu'en anglais, "except" veut dire "sauf", "à
l'exception/exclusion de". Pourquoi ne pas avoir utilisé "exception" ?
Ou, si économiser 3 caractères était aussi essentiel "error", qui aurait
été sans ambiguité.

Ce genre de choses, comme join(), violent royalement le principe de
moindre surprise, et rendent la vie du mainteneur difficile.


--
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.