Si on pouvait vraiment parler de sucre syntaxique à propos de int(string), alors string.int() serait possible ce qui n'est pas le cas, donc le sucre n'a pas grand chose à voir ici. int() est un builtin, point, et c'est une décision dont je ne vois aucun intérêt, mais tu vas peut-être pouvoir m'éclairer. Ce qui fait en partie la force d'un langage malgré ce que pensent beaucoup, c'est sa bilbiothèque standard. Python a bien joué, il possède une bibliothèque standard très étendue. Mais il faut aussi qu'elle soit de qualité ; et une des qualités c'est l'orthogonalité, la logique qu'elle montre. L'ensemble des opérations de base sur les chaînes doivent être disponibles en tant que méthode sur les instances de cette classe, ça me paraît peu discutable, quand même ?
Tout est objet dans Python, mais manque de bol pour une fonction fondamentale comme la longueur d'une chaine il faut écrire 4 underscores pour obtenir la fonction. Pourquoi, une méthode len() c'était trop simple ? Ah non __len__() c'est mieux, ça va amuser les programmeurs de tapper 4 underscores, et ça va faire des programmes très lisibles puisque la qualité de Python c'est de donner des programmes lisibles...
Quant à la surcharge d'opérateurs, étant donné que Perl se prête moyennement à l'objet... Mais j'ai déjà dit et répété que Perl suxait pour pas mal de points, et pour l'objet c'est clair que c'est une de mes critiques les plus importantes (relis mon dernier post plus haut, je n'ai jamais affirmé que Perl était la panacée pour les gros programmes, surtout ceux qui se prêtent particulièrement à l'objet). Si je veux faire un programme conséquent en objet, qui n'a pas besoin impératif de performance ou de vérifications fortes avant l'exécution, je choisis Ruby, bien sûr.
J'ai répondu aux quatre critiques avancées et j'ai montré qu'elles ne tenaient pas.
Ça n'était donc que ça qui te retenait de passer à python ? Parfait, bienvenue au club !
Euh, bof :) je consens que le problème sur l'appel du constructeur père était du à mon ignorance de Python ; sur les closures tu as au contraire montré toi-même qu'elles n'étaient pas dispo et qu'on obtenait un programme long et verbeux (je peux faire du C pour faire ça merci ;p) ; sur l'interpolation des chaînes tu as au contraire montré toi-même que ce n'était pas possible ; et enfin sur le manque d'"orthodoxie objet" sur la classe string, ta réponse est de t'émerveiller d'une méthode __len__() et d'un builtin int(), en disant que si on n'est pas content on peut écrire ces méthodes soi-même (je me demande l'utilité d'écrire des méthodes dans une bibliothèque de base si c'est pour ensuite proposer aux gens d'en écrire d'autres soi-même).
[^] # Re: objet ? pas objet ?
Posté par gc . En réponse au message de la puissance de (beep) pour trouver un truc simple en 2 minutes. Évalué à 2.
Tout est objet dans Python, mais manque de bol pour une fonction fondamentale comme la longueur d'une chaine il faut écrire 4 underscores pour obtenir la fonction. Pourquoi, une méthode len() c'était trop simple ? Ah non __len__() c'est mieux, ça va amuser les programmeurs de tapper 4 underscores, et ça va faire des programmes très lisibles puisque la qualité de Python c'est de donner des programmes lisibles...
Quant à la surcharge d'opérateurs, étant donné que Perl se prête moyennement à l'objet... Mais j'ai déjà dit et répété que Perl suxait pour pas mal de points, et pour l'objet c'est clair que c'est une de mes critiques les plus importantes (relis mon dernier post plus haut, je n'ai jamais affirmé que Perl était la panacée pour les gros programmes, surtout ceux qui se prêtent particulièrement à l'objet). Si je veux faire un programme conséquent en objet, qui n'a pas besoin impératif de performance ou de vérifications fortes avant l'exécution, je choisis Ruby, bien sûr.
J'ai répondu aux quatre critiques avancées et j'ai montré qu'elles ne tenaient pas.
Ça n'était donc que ça qui te retenait de passer à python ? Parfait, bienvenue au club !
Euh, bof :) je consens que le problème sur l'appel du constructeur père était du à mon ignorance de Python ; sur les closures tu as au contraire montré toi-même qu'elles n'étaient pas dispo et qu'on obtenait un programme long et verbeux (je peux faire du C pour faire ça merci ;p) ; sur l'interpolation des chaînes tu as au contraire montré toi-même que ce n'était pas possible ; et enfin sur le manque d'"orthodoxie objet" sur la classe string, ta réponse est de t'émerveiller d'une méthode __len__() et d'un builtin int(), en disant que si on n'est pas content on peut écrire ces méthodes soi-même (je me demande l'utilité d'écrire des méthodes dans une bibliothèque de base si c'est pour ensuite proposer aux gens d'en écrire d'autres soi-même).