Du coup certains ont implémenté les interfaces dans des libs non standard.
Oui, en même temps le fait que ce soit possible est plutôt une qualité du langage. Python évite l'inflation de mots-clés en fournissant un langage souple qui permet aux programmeurs de réaliser les abstractions dont ils ont besoin sans que ça ait l'air affreux.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
Au fait, je ne sais pas ce qui a pu te faire arriver à la conclusion que l'héritage multiple de Python se fait en profondeur d'abord :
>>> class A(object): pass
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(B, C): pass
...
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <type 'object'>)
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
Ceci dit quand on se retrouve avec un graphe d'héritage suffisamment compliqué pour que les relations de précédence ne soient pas triviales, c'est un signe de mauvaise conception. Surtout si on donne le même nom à des méthodes à différents endroits du graphe, avec des sémantiques différentes.
Tu n'as pas d'attributs ou de méthodes protégées.
C'est quoi le problème à résoudre ?
Si tu veux déclarer qu'un attribut est à usage interne, tu n'as qu'à le préfixer d'un underscore, c'est une convention suffisamment explicite pour indiquer à l'utilisateur de ta classe qu'il ne faut pas toucher à cet attribut-là.
Si l'utilisateur en question est assez téméraire pour passer outre, c'est son problème.
La philosophie de Python n'est pas de prendre les développeurs pour des enfants et de mettre des barrières partout (contrairement à Java qui favorise le contexte social d'une informatique réalisée par une armée de tâcherons sous-payés et incompétents) ; c'est un langage pour adultes consentants. A chacun d'être à la hauteur.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
C'est effectivement élégant parce que cela implique qu'une méthode est l'équivalent d'une fonction.
Le langage est ainsi plus orthogonal, et il n'y a pas de variable au statut particulier ou magique (comme "this").
(oui, en Java il n'y a pas de fonctions proprement dites, du coup pour compenser il y a des "méthodes" statiques, qui ne sont des méthodes que sur le plan syntaxique et non sémantique, comme c'est rigolo)
Si des langages comme Java n'imposent pas de devoir taper "self", ils imposent de taper systématiquement "private", "public" et toute une inflation délirante de mots-clés, enfin bref...
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 1.
Parce que le typage statique permet aux programmes de se "déverminer" sans intervention humaine peut-être ? Voilà une nouvelle inattendue.
pas de libs standard équivalente aux servlets, aucune spécification commune
Python Web Server Gateway Interface
http://www.python.org/dev/peps/pep-0333/
Du coup certains ont implémenté les interfaces dans des libs non standard.
Oui, en même temps le fait que ce soit possible est plutôt une qualité du langage. Python évite l'inflation de mots-clés en fournissant un langage souple qui permet aux programmeurs de réaliser les abstractions dont ils ont besoin sans que ça ait l'air affreux.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
Au fait, je ne sais pas ce qui a pu te faire arriver à la conclusion que l'héritage multiple de Python se fait en profondeur d'abord :
>>> class A(object): pass
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(B, C): pass
...
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <type 'object'>)
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
Ceci dit quand on se retrouve avec un graphe d'héritage suffisamment compliqué pour que les relations de précédence ne soient pas triviales, c'est un signe de mauvaise conception. Surtout si on donne le même nom à des méthodes à différents endroits du graphe, avec des sémantiques différentes.
Tu n'as pas d'attributs ou de méthodes protégées.
C'est quoi le problème à résoudre ?
Si tu veux déclarer qu'un attribut est à usage interne, tu n'as qu'à le préfixer d'un underscore, c'est une convention suffisamment explicite pour indiquer à l'utilisateur de ta classe qu'il ne faut pas toucher à cet attribut-là.
Si l'utilisateur en question est assez téméraire pour passer outre, c'est son problème.
La philosophie de Python n'est pas de prendre les développeurs pour des enfants et de mettre des barrières partout (contrairement à Java qui favorise le contexte social d'une informatique réalisée par une armée de tâcherons sous-payés et incompétents) ; c'est un langage pour adultes consentants. A chacun d'être à la hauteur.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
C'est effectivement élégant parce que cela implique qu'une méthode est l'équivalent d'une fonction.
Le langage est ainsi plus orthogonal, et il n'y a pas de variable au statut particulier ou magique (comme "this").
(oui, en Java il n'y a pas de fonctions proprement dites, du coup pour compenser il y a des "méthodes" statiques, qui ne sont des méthodes que sur le plan syntaxique et non sémantique, comme c'est rigolo)
Si des langages comme Java n'imposent pas de devoir taper "self", ils imposent de taper systématiquement "private", "public" et toute une inflation délirante de mots-clés, enfin bref...