Antoine a écrit 5722 commentaires

Tout n'est question de convention et d'homogénéité, et on peut faire l'inverse si on veut.

Oui, le problème c'est qu'il n'y a vraiment pas homogénéité dans les conventions d'une lib à l'autre.
D'où l'intérêt des exceptions qui permettent que tout soit clair sur la signification du retour.

Si tu en es vraiment convaincu, tu pourrais éviter de garder ton argumentation implicite.

Je n'en suis pas "vraiment convaincu", je rappelle juste la règle qui justifie ce choix. Après, chacun a le droit d'être en désaccord, c'est juste qu'il y a une cohérence dans la conception du langage.

Pourquoi join ne convertit pas automatiquement en string, sachant que join n'accepte que les strings

Précisément parce qu'ainsi, tu lèves les erreurs tôt plutôt que tard. Quiconque a déjà programmé en PHP sait à quel point c'est préférable ;-))

quand il n'y a pas d'ambiguité, forcer la convertion explicite n'a pas l'air justifié

Oui, comme ça une erreur dans ton programme apparaît cent lignes plus tard sous une forme incompréhensible plutôt qu'en levant la bonne exception au bon endroit...

D'autant que la conversion explicite n'est pas bien lourde à écrire. Par exemple : "".join(str(x) for x in my_iterator)
(on peut aussi choisir une notation plus fonctionnelle avec map ou imap)

Je commence à croire que tu considères que si c'est possible en Python, alors ça ne mérite pas d'être mentionné pour les autres langages.

Ce n'est pas que ça mérite pas d'être mentionné.
C'est juste que l'idée originale (exprimée par un posteur plus haut) que "Ruby est le seul langage populaire à avoir des itérateurs bien implémentés" est un mensonge.
Mais je suis d'accord que les mêmes concepts exprimés en C, assembleur ou même PHP sont bigrement moins élégants.

Si tu fais un dérivé uniquement en binaires, ton dérivé n'est pas libre

Oui, et pourtant le dérivé est bien sous BSD lui aussi.
Merci d'avoir confirmé ce que voulais dire :-)

En Python, à peu près tous les objets sont aussi convertibles en chaîne avec le constructeur str() (qui appelle la méthode __str__() en sous-main), mais join() ne fait pas la conversion pour toi : explicit is better than implicit.

Est-ce que j'ai donné un exemple idiot et académique, ou bien est-ce que j'ai donné un exemple trop spécifique et que j'aurais dû généraliser à tous les itérateurs ?

Les deux :-)
Ainsi, la raison pour laquelle la fonction takewhile() est fournie dans les modules standard de Python, c'est qu'elle y est écrite en C et permet donc des gains de performance substantiels sur certains algorithmes. Sinon, c'est une primitive qui s'écrit en quatre lignes de Python, ça n'a donc pas grand intérêt de l'abstraire : pareil pour le foreach_while.

La morale, c'est que l'exemple donné des trucs géniaux qu'on peut faire avec les itérateurs de Ruby 1) se fait aussi sans problème dans d'autres langages 2) n'apporte à peu près rien en pratique.

Python 2.5.1 (r251:54863, Sep 13 2007, 09:06:49)
[GCC 4.2.1 20070828 (prerelease) (4.2.1-6mdv2008.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class InfiniteException(Exception):
...       def __init__(self):
...           raise InfiniteException()
...
>>> raise InfiniteException()
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in __init__
[ ... beaucoup de lignes plus loin ... ]
File "", line 3, in __init__
RuntimeError: maximum recursion depth exceeded
>>>

Le fait d'avoir un GC n'y change rien : si les données ne tiennent pas en mémoire, il n'y a plus qu'à abandonner. Donc traiter l'erreur ne sert à rien : autant laisser l'exception remonter la pile d'appels jusqu'à entraîner la terminaison du programme.

Oui, PHP affiche un warning débile à l'écran (en espérant que quelqu'un le voie) et continue son exécution comme si de rien n'était.

Par exemple je peux t'écrire un exemple où on veut parcourir un graphe en profondeur, et s'arrêter au premier sommet non marqué. C'est typiquement une variante de foreach_while.

Oui mais tu n'as nullement besoin du foreach_while avec ses blocs de code. Tu peux très bien utiliser une fonction de haut niveau prenant en paramètre un itérateur et un prédicat, et retournant un nouvel itérateur qui renvoie la même chose que le premier jusqu'à ce que le prédicat devienne vrai.

C'est exactement ce que fait la fonction takewhile() du module standard itertools en Python ( http://docs.python.org/lib/itertools-functions.html ).

tu n'as pas fait de Python 1.x comme j'ai pu en faire

Effectivement je n'en ai pas fait. Ceci dit ce n'est pas terriblement important, vu que Python en est à la version 2.5 et qu'une alpha (très alpha certes) de la 3.0 est déjà sortie...

encore une fois tu diverges du sujet initial

La paille et la poutre ?

Bon, on ne saura apparemment jamais pourquoi "les itérateurs de Ruby sont mieux implémentés". Merci pour cette belle intervention :)

nos exemples montrent différentes manière d'écrire un itérateur "foreach_while".

C'est bien ce que j'appelle un exemple académique sans incidence sur le monde réel. Dans la vraie vie, on a autre chose à faire que d'implémenter ou réimplémenter des "itérateurs foreach_while", cette dernière chose n'ayant aucune utilité.

J'ai du mal à comprendre pourquoi join est une méthode de la chaîne, et pas du tableau.

Précisément parce que join peut accepter autre chose que des listes en argument. Dans mon exemple join reçoit un itérateur. N'importe quel objet peut être un itérateur s'il implémente le protocole idoine (très simple).

Mais dans la notation "5.times { ... }", on pourra arguer de même que c'est le bloc de code qui s'exécute cinq fois, et non le nombre 5 qui effectue l'opération de répéter le bloc. Ou alors pourquoi pas "true.if { ... }" ? (et là je suis sûr qu'il y en a qui vont me répondre qu'ils l'ont fait)

Quant au fait d'apprendre le Python avant d'avoir le droit de te répondre

Oui mais savoir que le signe "." réalise un accès d'attribut ou de méthode plutôt qu'une concaténation de chaînes, ce n'est pas à proprement parler apprendre le Python, c'est juste savoir grosso modo à quoi ressemble le langage :-)

Ainsi je n'ai pas eu besoin d'apprendre le Ruby pour comprendre vos exemples.

Je suppose que "str(i) for i in t" construit un tableau ou une liste

Non justement, ça construit un itérateur, d'où le rapport avec vos exemples.

Et si vos exemples sont stupides, c'est parce qu'ils portent sur un type de code qui est absolument inutile dans la vraie vie (afficher tous les entiers de 1 à 10, chouette...). Un langage qui est plus "joli" sur des exemples totalement académiques, la belle affaire.

j'ai du mal à comprendre pourquoi join est une méthode de la chaîne

Et tu n'as pas de mal à comprendre pourquoi "times" est une méthode des entiers en Ruby ? Marrant ça, je croyais que la notation objet était naturelle pour les rubyistes ?

Ou alors "toto".join n'est pas un appel de méthode comme ça en a l'air, mais "." est l'opérateur de concaténation

Heu, comment dire, peux-tu lire un peu de doc sur Python histoire qu'on évite ce genre de question basique ? :-)

Ton exemple n'a rien à voir avec celui que j'ai repris.

Essaie d'argumenter un peu, sinon ça ne va pas très loin...

- Parce que Ruby a intégré les itérateur et les blocs de code depuis la première version ?

Je ne vois pas le rapport entre "implémenté avant" et "mieux implémenté".

Parce qu'en Ruby tout les types (y compris les nombres) sont des de vrais objets

En Python aussi. Oui, y compris les nombres, les classes, les modules, les fonctions...

Parce qu'en Python tout ceci n'a été ajouté que tardivement, et que ça se ressent dans la syntaxe

Ca ne se "ressent" que parce que tu as une vision religieuse des choses liée à ton expérience avec Ruby. En fait c'est très naturel : une fonction est la même chose qu'une méthode (on peut d'ailleurs binder l'une sur l'autre), c'est donc normal que le self soit explicite. De même le cls est explicite sur les méthodes de classe.

Et c'est avant tout justifié par un principe directeur de Python : explicit is better than implicit. En Python il y a peu de magie, la logique est apparente partout, contrairement à Perl et dans une moindre mesure Ruby.

Dire que c'est à cause d'une limitation quelconque du langage qu'il n'y a pas de self implicite est une grossière erreur : il n'aurait pas été compliqué de modifier l'instantiation des méthodes pour rajouter la logique correspondante. Il y a même des gens qui se sont amusés à implémenter cela en pur Python, sans toucher à l'interpréteur ( http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3623(...) ).

... Ceci dit, la question d'origine est "en quoi les itérateurs de Ruby sont-ils mieux implémentés", et tu n'as pas répondu. :-)

Un logiciel sous licence reconnue par la FSF est libre à 100 %.

Non, pas forcément.
Par exemple je prends un logiciel sous BSD, je fais une version dérivée également sous BSD. Je ne distribue que des binaires sans fournir le source à personne. La licence est reconnue par la FSF, mais le logiciel n'est pas libre car la personne qui le reçoit ne dispose pas de la liberté d'étudier.

Il faut bien distinguer licence libre (licence permettant, mais n'imposant pas forcément, au logiciel d'être libre) et logiciel libre.

De toute façon, c'est un domaine où la "scalabilité" est cruciale, alors avec un bon load balancing et un nombre suffisant de serveurs, ça devrait plus poser de problème, si ?

L'association Linuxfr compte sur toi pour acheter tous ces serveurs :)

# On construit un tableau de 10 entiers
t = range(10)
# On convertit tout en itérant et on accumule le tout
print "\n".join(str(i) for i in t)

Concis et stylé, du Python quoi !
Vous en avez d'autres, des exemples stupides ? :)

mais Ruby est celui qui les implémente le mieux parmi les langages les plus couramment utilisés

Mmmh plus précisément ? En quoi les implémente-t-il "mieux" que, par exemple, Python ?

Perso le PHP demande beaucoup beaucoup plus de rigueur du fait de sa permissivité. Quand un language a un haut niveau de repport d'erreur on a tendance a se reposer sur lui, et du coup le jour ou il laisse passé un trucs qu'on avait pas prévu ben on est tout pantois.

Ah oui ça c'est l'argument qui tue : PHP est nul, mais comme on sait que PHP est nul on ne risque pas d'être surpris. Il respecte donc le Principle of Least Astonishment.

Y a une logique derreire ca et n'importe quel livre de base en PHP l'explique.


Mouais... La logique, c'est surtout que ça été conçu par un guignol qui a trouvé intelligent d'avoir des conversions implicites dans tous les sens histoire de taper x au lieu de str(x).

Je relève ce passage étonnant : « AdaCore est une entreprise 100% Logiciel Libre dont le modèle commercial repose sur un abonnement annuel comprenant la mise à disposition d'outils de développement sous une licence adaptée aux usages industriels ».
Il faudra qu'on m'explique ce qu'est une entreprise « 100% Logiciel Libre » qui vend(rait) du logiciel propriétaire ??

On a déjà buté sur ce mystère AdaCore lorsqu'on a écrit notre comparatif de logiciels libres, chez Libroscope :
http://www.libroscope.org/Benchmark-23-logiciels-libres

l'objectif n'est pas tant d'informer les libristes

Ah, c'est peut-être un peu dommage que l'APRIL ne se soucie pas d'informer les libristes...

j'ai juste relevé le fait que vous hierarchisez les haines

Personne n'a hiérarchisé les haines en l'occurence, encore une fois tu lis tout de travers.
Dire qu'antisémite et raciste sont deux choses différentes est évident, il suffit de lire la définition. Cela n'empêche que beaucoup d'antisémitismes relèvent du racisme, mais bon.

Quand j'entends Sarkozy ou autres parler d'antisémitisme et de racisme, je trouve que c'est une erreur assez grave.

Marrant, moi il y a des choses beaucoup plus graves qui me gênent chez Sarkozy :-)

Tu es donc tout simplement facho, vu que tu es contre la liberté d'expression.

Oh mais c'est joli ça.
Non seulement être contre la liberté d'expression n'implique pas être "être facho" : n'en déplaise à tes conceptions simplistes et tes argumentations à l'emporte-pièce, le mot fascisme réfère à quelque chose de plus précis (n'étant pas à une contradiction près, tu le prouves toi-même en citant la définition de Wikipédia).

De plus vouloir limiter/encadrer la portée de la liberté d'expression ne veut pas dire être contre cette liberté, c'est simplement l'affirmation d'une conception de la liberté assez courante en Europe (c'est aussi, dans le cas très précis des opinions racistes et antisémites, en réponse à une période historique bien connue... j'espère que cette particularité ne t'a pas échappé). Qu'on soit d'accord ou pas avec cette conception (il est évident que ça se discute, il y a d'ailleurs des historiens renommés qui sont contre la loi Gayssot), ne justifie en rien la description que tu en fais.