totof2000 a écrit 9656 commentaires

En l'occurrence je reprocherais plutôt un problème de cohérence

C'est bien ça qui me gène avec Python : une incohérence que l'obn retrouve sur plein de choses qui paraissent des détails, mais qui, mis bout à bout, rendent le développement un peu pénible.

Le choix a été fait il y au longtemps par Guido, avec l'argument suivant: il estimait que la forme Python était plus lisible et plus facile à comprendre

Elle n'est pas logique par rapport à la logique "objet".

Ce qui me gène par contre, c'est l'argument que à cause de ce choix de syntaxe, Python ne serait pas un langage objet.

Ce n'est pas ce que j'ai dit. D'ailleurs j'ai posé la question avant d'affirmer. Je dis simplement que ce n'est pas cohérent avec la logique "objet".

Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

Le C++ n'est pas un langage objet. Les types de base ne sont pas des objets. De mémoire tu ne peux pas dériver ton propre type à partir d'un int, ni surcharger une méthode de int, dans la mesure ou int n'est pas un objet.

Est-ce que interdire la fonction main() comme le fait java en fait un langage plus objet qu'un langage où on appelle une fonction main() ?

Java n'est pas plus objet que C++ pour les mêmes raison. aucun rapport avec main.

Je ne pense pas que VNC soit une solution viable pour une station de travail.

A une époque j'aurais parlé de xdmcp, mais comme certains ont décidé que ce genre de fonctionnalité ne sert à rien (la preuve ici que ça sert), ce genre de truc risque de disparaitre avec Wayland par exemple.

Je précise pourquoi je te dis ça : il m'est arrivé, dans un cas de partage de fichier depuis une machine, de constater une nette amélioration de performances en passant de l'interface réseau intégrée à une interface réseau ajoutée. Les cartes avaient le même débit (100 Mb me semble-t-il), mais le changement a été assez spectaculaire. Je n'ai pas creeusé pour savoir ce qui pouvait bien causer cette différence, mais il y a plusieurs choses qui me viennent à l'idée :
- un chipset buggé : ça peut arriver.
- sur certaines cartes, certaines actions sont réalisées au niveau du chipset, et non au niveau du CPU de la machine hôte : ceci a pour effet de diminuer le nombre d'interruptions, de changement de contexte et d'avoir de meilleures perfs.

Il peut probablement y avoir d'autre raisons (qualité des soudures sur les interfaces, etc ….) mais en gros, ne te prove pas de pouvoir changer d'interface réseau si les perfs du chipset intégré ne te satisfont pas.

Si tu veux faire faire tout ça à ta machine, ne lésine pas sur la qualité des interfaces réseau. Autant pour le client, une interface de base devrait suffire, autant pour le serveur vaudrait-il mieux investir dans une interface performante (voire en utiliser 2).

Celà dit, le fait d'avoir cette convention (utiliser les __ __ pour ce genre de méthode ) n'est pas gênant. C'est une convention du langage comme une autre et qui peut être pratique.

La tout de suite ? non pas vraiment car ça fait un moment que je n'ai pas fait de python. Je devrais en refaire bientôt et je nemanquerai pas de relever tout ces points pour en faire un journal du Vendredi …

Là on s'éloigne un peu du sujet initial quelque part (et je me suis laissé avoir) : pour ma part j'ai pris l'exemple de (1).__class__ comme j'aurais pu prendre autre chose : ma question initiale était de savoir si les types de base sont des objets et j'ai eu ma réponse. Et justement, c'est le fait d'utiliser type() qui m'a induit en erreur et qui m'a mis le doute. Et c'est là que je croyais voir une incohérence (qui n'existe pas) avec le paradigme objet : ne pas pouvoir demander à un objet son type et devoir passer par une autre fonction. Vous m'avez montré que c'est possible donc je n'ai plus rien à ajouter. Au passage, si on prend Ruby (encore), lorsqu'on veut par exemple convertir un tableau en chaine, on utilise la méthode to_s de l'objet. Peut-on faire la même chose en Python ou doit-on utiliser une fonction à qui on passera en paramètre une instance d'objet (comme type()) ?

Pourquoi faire ?

Hein ? Pour demander à un objet de retourner son type, il faut demander à une fonction extérieure ? C'est ce manque de cohérence que je reproche à Python (mais il m'a été démontré hereusement que l'objet lui-même est capabble de retourner son type).

Quand on trolle on utilise n'importe quelle source qui pourrait sembler appuyer ses "arguments " :).

Plus sérieusement, ce que je n'aime pas dans Python par rapport à Ruby, c'est le manque de concision dans la façon d'écrire le code: mais ça c'est plus une question de gout qu'un réel problème technique.

J'en sais rien. Mais OSEF, non ?

Non, c'est une question de logique et de cohérence. Un article récent de GLMF expliquait que le fait par exemple que Java ne soit pas full object a poussé les développeurs à créerr des patterns permettant de pallier ce problème, mais au prix d'une plus grande complexité.

Par contre on m'a expliqué pourquoi ce que j'ai tenté de faire ne marche pas et ça me parait logique (le fait que l'interprêteur s'attend à avoir un chiffre derrière le 1).

Tu mets en évidence un second reproche que je fais à Python.

En ruby, pour faire la même chose je fais simplement :

irb(main):002:0> 1.methods()
=> ["%", "odd?", "inspect", "prec_i", "<<", "tap", "div", "&", "clone", ">>", "public_methods", "__send__", "object_id", "instance_variable_defined?", "equal?", "freeze", "to_sym", "*", "ord", "+", "extend", "next", "send", "round", "methods", "prec_f", "-", "even?", "singleton_method_added", "divmod", "hash", "/", "integer?", "downto", "dup", "to_enum", "instance_variables", "|", "eql?", "size", "instance_eval", "truncate", "~", "id", "to_i", "singleton_methods", "modulo", "taint", "zero?", "times", "instance_variable_get", "frozen?", "enum_for", "display", "instance_of?", "^", "method", "to_a", "+@", "-@", "quo", "instance_exec", "type", "**", "upto", "to_f", "<", "step", "protected_methods", "<=>", "between?", "==", "remainder", ">", "===", "to_int", "nonzero?", "pred", "instance_variable_set", "coerce", "respond_to?", "kind_of?", "floor", "succ", ">=", "prec", "to_s", "<=", "fdiv", "class", "private_methods", "=~", "tainted?", "__id__", "abs", "untaint", "nil?", "chr", "id2name", "is_a?", "ceil", "[]"]

Je me réponds à moi-même pour la dernière partie : on utilise la méthoe class qui fonctionne bizarrement :

>>> "a".__class__
<type 'str'>
>>> 1.__class__
  File "<stdin>", line 1
    1.__class__
              ^

Si c'était vrai, on en serait encore à l'assembleur ou au Cobol.

Ben moi, non je n'approuve pas.

Python, c'est un peu le Visual Basic du Libre : un langage fait pour les gens qui "ne sont pas développeurs", qui leur permet de faire des trucs vite fait en console et les copier/coller dans un script, en donnant l'impression que c'est bien programmé parce que le code est bien indenté. Au final on obtient du code inélégant et inefficace. Enfin, ce qui me gène dans Python, c'est que certains le présentent comme tout objet. Mais est-il possible de faire la même chose que ci-dessous avec les types natifs ?

irb(main):006:0> 1.class()
=> Fixnum

Merci pour ce retour.

T'as pas toujours l'envie ou le temps de réinventer la roue, et ces frameworks te proposent une belle palanquée de plugins

Donc à mettre en balance le temps passé sur l'apprentissage et la prise en main du framework par rapport aux besoins et au temps passé à "réinventer la roue". Mais existe-t-il un moyen relativement simple de faire cette évaluation ? Autrment dit, si je reprends l'exemple d'un datepicker, est-ce que ça vaut le coup pour un champ date sur une page de l'ensemble du site ?

Côté serveur, je mettrais Erlang, avec mnesia en database entre autres choses parce qu'il permet les mises à jour à chaud, et parce que le concept même du langage (pas de programmation défensive) permet d'économiser des lignes de codes plus ou moins redondantes (par contre j'avoue que la syntaxe est parfois un peu lourde).

Je développerais une api REST pour laisser la possibilité aux personnes qui n'aimeraient pas mon client de développer le leur et éventuellement sous-traiter cet aspect à des développeurs plus compétents que moi dans ce domaine.

Côté client je ne sais pas : je ne connais pas trop les solutions. Probablement quelque chose à base de HTML5/Javascript. Par contre quel est l'intéret de passer par des frameworks style jquery et compagnie pour développer un client relativement simple? D'autre part, si on se limite à HTML5, est-ce réellement utile d'ajouter des couches telles que JQuery par exemple ? C'est une vraie question car je devrai y passer pour mes 2-3 projets lorsque j'aurai avancé suffisamment sur la partie serveur (je traine un peu des pieds pour m'y mettre d'ailleurs parce que c'est un peu la jungle de ce côté).

comprendre que tout ne se résume pas à l'argent

Mais l'argent te permet de mettre en place un workflow efficace plus facilement. Tu peux payer pour mettre en place des ressources matérielles, logicielles et humaines pour gérer ces problèmes, tandis que si tu n'as pas d'argent, tu devras compter sur des bénévoles, des dons ou du mécénat.

Merci pour ce commentaire : c'est plutôt ça que je voulais dire. Dans ce cas précis, Apple a fait moins bien qu'un amateur alors qu'ils disposent de moyens pour faire beaucoup mieux.

est-ce si difficile à comprendre que dans ce cas on considère Debian comme un jouet et à ne jamais mettre en prod car des gens considèrent que comme c'est gratuit on a un passe-droit sur la sécurité?

Rien à voir. Debian n'a pas la sécurité comme objectif principal affiché, même s'ils font de leur mieux pour garder leur distribution sure. Par contre dans le libre, je serais plus exigeant vis à vis d'OpenBSD par exemple car la sécurité est affichée comme objectif principal.

Désolé, je considère le libre (et Debian) comme quelque chose qui mérite plus que cette considération "c'est fait par un pote pas doué donc la qualité pourrie est acceptable".

Ce n'est pas ce que je voulais dire, même si c'est ce qui a pu paraitre dans mes propos. N'oublie pas que je n'ai pas forcément un point de vue aussi tranché que toi (ce n'est pas une insulte : je n'ai simplement pas d'autre mot qui me vient à l'esprit). Et il est clair que je n'utiliserais ni Debien , ni Linux dans certains cas. Si on parle de sécurité par exemple, j'aurais tendance à me tourner vers OpenBSD (peut-être même des solutions proprios basées sur OpenBSD).

Je comprends ton point de vu mais je le trouve insultant et paternaliste avec un projet (entre autre) qui n'a rien des amateurs avec les quels tu le compare.

Je suis peut-être allé un peu trop loin dans la comparaison. Je ne veux pas dénigrer Debian non plus, car je sais que le travail accompli est remarquable. Je voulais juste mettre en évidence que l'on est en droit d'être plus exigeant d'un service payant que d'un service gratuit. Et si on rest edans le libre, je serais beaucoup plus exigeant vis à vis de Canonical, RedHat, ou Suse pour leurs distributions par rapport à Debian dans le cas ou je paierais le service adéquat. Sinon quelle serait leur valeur ajoutée ?

Personnellement je vois une différence de taille : un produit Apple, je le paye (enfin non, je ne le paye pas mais si j'étais client, je le payerais). Pas une Debian. Rien que pour ça je suis plus exigeant vis à vis d'Apple que de Debian par exemple. Et c'est normal pour n'importe quoi d'autre : je serai plus exigeant d'un meccano pro qui touche à ma voiture et qui me facturera la main d'oeuvre bien chère, alors que si c'est un ami ou mon neveu qui répare ma voiture, je le serai beaucoup moins.

Est-ce si difficile à comprendre ?

C'est une des raisons pour lesquelles je n'aime pas trop Python : ce genre de problème m'est arrivé plusieurs fois suite à des suppression ou ajouts de blocs dans le code. Là ou un langage classique m'aurait sorti qu'il manque une } ou un end, Python a bien compilé/exécuté le code et j'ai mis des heures à trouver le problème.

A quoi celà pourrait-il servir ? C'est une vraie question.