Accessoirement, le typage statique semble faire couler pas mal d'encre dans la communauté python actuellement
Alors que dans la majorité des cas, un typage statique est demandé par "habitude", parce que les autres langages utilisent ça.
En python, on préfère utiliser le duck typing : si ça marche en canard et que ça fait "CO1N !", on le traite comme un canard (non non, pas comme une moule). Un raisonnement assez proche de celui mis en place avec l'inférence de type. Ce qui est intéressant, ce sont les capacités de ton objet, pas son type.
Ainsi, pour le premier exemple, f1 ne demande pas un entier en argument, mais n'importe quel "truc" auquel on peut ajouter un entier. Un entier ou un long, un float, un Decimal en python2.4, un complexe, ou n'importe quelle classe définie par moi et qui accepte qu'on lui ajoute 1.
[^] # Re: OCaml & python ont vraiment des approches et possibilités différente
Posté par Amand Tihon (site web personnel) . En réponse au journal pas d'inference de type a la ocmal en python. Évalué à 4.
Alors que dans la majorité des cas, un typage statique est demandé par "habitude", parce que les autres langages utilisent ça.
En python, on préfère utiliser le duck typing : si ça marche en canard et que ça fait "CO1N !", on le traite comme un canard (non non, pas comme une moule). Un raisonnement assez proche de celui mis en place avec l'inférence de type. Ce qui est intéressant, ce sont les capacités de ton objet, pas son type.
Ainsi, pour le premier exemple, f1 ne demande pas un entier en argument, mais n'importe quel "truc" auquel on peut ajouter un entier. Un entier ou un long, un float, un Decimal en python2.4, un complexe, ou n'importe quelle classe définie par moi et qui accepte qu'on lui ajoute 1.