> quoi de plus destabilisant qu'une fonction qui prend un paramètre dont le nom est pas très explicite et dont on connais pas le type...
Normalement, les types possibles des paramètres et des valeurs de retour doivent être documentés. Après, c'est certain que le langage n'interdit personne à mal coder, hein :)
> la doc est fouilli... trouvé quelque chose n'est pas toujours simple. Comparé avec la doc de Qt ou de Java
La doc de Qt, je ne sais pas. J'en ai entendu beaucoup de bien, même si je l'ai jamais essayée moi même. Mais honnêtement, ma maigre expérience de Java a été un cauchemar au niveau documentation en ligne (peut être que la doc intégrée aux IDEs est meilleure...). Honnêtement, je vois très mal comment préférer http://java.sun.com/j2se/1.4.2/docs/api/ à http://docs.python.org/
> - beaucoup de reste d'un langage pas objet à la base
Pardon ???
Il va falloir epliquer plus profondément que ça. Quand tu sais que même les modules, les classes et les fonctions sont des objets, je vois mal ce qu'il te manque ;)
>- de même, j'ai tendance a oublier les self....
Ça m'a pris quelques mois pour attraper le réflexe, mais c'est vrai que c'est dur, au début ;)
> Bref, en fait la seul chose que j'aimerais ça serait d'avoir un typage obligatoire
Tu enlèves là un gros avantage du langage. Même si dans, disons, 80% des cas, le type est connu à l'avance, le typage fort (ou, le typage de python est fort) dynamique est carrément jouissif dans les 20% autres cas (surtout quand tu penses au nombre de lignes supplémentaires que ça aurait pris dans un langage à typage statique). Certaines choses que j'ai faites proprement en Python en quelques lignes grâce à ce typage dynamique m'auraient prises plusieurs fichiers et une bonne centaine de lignes en Java.
> Ou alors Python va-t-il s'améliorer avec Py3k ?
Pour l'autocompletion, un truc asez intéressant va arriver dans Python 3k: la possibilité d'annoter les fonctions. Par exemple, les définitions suivantes deviennent valide en Python 3000:
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
Par défaut, l'interpréteur n'en fait rien, mais on peut très bien l'utiliser comme:
- documentation
- dire quels types sont supportés
- vérification de type à l'aide d'un décorateur
Après, il faut bien sûr que les IDEs en tirent partie. Mais c'est là une autre histoire :)
[^] # Re: troll de noel
Posté par Moonz . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 2.
Normalement, les types possibles des paramètres et des valeurs de retour doivent être documentés. Après, c'est certain que le langage n'interdit personne à mal coder, hein :)
> la doc est fouilli... trouvé quelque chose n'est pas toujours simple. Comparé avec la doc de Qt ou de Java
La doc de Qt, je ne sais pas. J'en ai entendu beaucoup de bien, même si je l'ai jamais essayée moi même. Mais honnêtement, ma maigre expérience de Java a été un cauchemar au niveau documentation en ligne (peut être que la doc intégrée aux IDEs est meilleure...). Honnêtement, je vois très mal comment préférer http://java.sun.com/j2se/1.4.2/docs/api/ à http://docs.python.org/
> - beaucoup de reste d'un langage pas objet à la base
Pardon ???
Il va falloir epliquer plus profondément que ça. Quand tu sais que même les modules, les classes et les fonctions sont des objets, je vois mal ce qu'il te manque ;)
>- de même, j'ai tendance a oublier les self....
Ça m'a pris quelques mois pour attraper le réflexe, mais c'est vrai que c'est dur, au début ;)
> Bref, en fait la seul chose que j'aimerais ça serait d'avoir un typage obligatoire
Tu enlèves là un gros avantage du langage. Même si dans, disons, 80% des cas, le type est connu à l'avance, le typage fort (ou, le typage de python est fort) dynamique est carrément jouissif dans les 20% autres cas (surtout quand tu penses au nombre de lignes supplémentaires que ça aurait pris dans un langage à typage statique). Certaines choses que j'ai faites proprement en Python en quelques lignes grâce à ce typage dynamique m'auraient prises plusieurs fichiers et une bonne centaine de lignes en Java.
> Ou alors Python va-t-il s'améliorer avec Py3k ?
Pour l'autocompletion, un truc asez intéressant va arriver dans Python 3k: la possibilité d'annoter les fonctions. Par exemple, les définitions suivantes deviennent valide en Python 3000:
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
Par défaut, l'interpréteur n'en fait rien, mais on peut très bien l'utiliser comme:
- documentation
- dire quels types sont supportés
- vérification de type à l'aide d'un décorateur
Après, il faut bien sûr que les IDEs en tirent partie. Mais c'est là une autre histoire :)
Et ruby répond à ton problème du self ;)