Je ne suis pas sûr d'avoir compris le commentaire de Groumly, j'espère que je ne réponds pas à côté. En tout cas je suis d'accord avec flan sur la conclusion.
@Groumly : lorsque tu fais du polymorphisme en Java, tu ne testes pas les types, cela va appeler la bonne méthode. Et bien en Python c'est la même chose en encore plus flexible. Mais ce qui te gêne c'est donc si on balance un objet qui a le malheur d'avoir une méthode avec le bon nom. Et bien c'est incorrect et ça produira une mauvaise sortie. On peut regretter de ne pas voir le problème dès la compilation d'où le besoin d'annoter les types. Sinon on le verra au niveau des tests unitaires s'ils sont bien faits.
Donc vraiment, c'est très rare d'avoir besoin de filtrer et surtout ce n'est pas une obligation. Ce n'est pas parce que je fais une fonction foo que je suis obligé de la rendre générique pour tous les types imaginables.
Si en Java tu as le choix entre deux méthodes A et B avec la même signature alors tu peux remplacer l'appel à la méthode A par la méthode B sans problème de compilation. Ça ne fera certainement pas ce que tu voulais à l'exécution...
Bon et bien là c'est pareil (en pire car le type n'est pas précisé donc plus simple de se planter) : si tu n'appelles pas la bonne fonction, on ne peut plus rien pour toi.
[^] # Re: Formulation...
Posté par Maxime (site web personnel) . En réponse au journal Indication de type pour Python. Évalué à 4.
Je ne suis pas sûr d'avoir compris le commentaire de Groumly, j'espère que je ne réponds pas à côté. En tout cas je suis d'accord avec flan sur la conclusion.
@Groumly : lorsque tu fais du polymorphisme en Java, tu ne testes pas les types, cela va appeler la bonne méthode. Et bien en Python c'est la même chose en encore plus flexible. Mais ce qui te gêne c'est donc si on balance un objet qui a le malheur d'avoir une méthode avec le bon nom. Et bien c'est incorrect et ça produira une mauvaise sortie. On peut regretter de ne pas voir le problème dès la compilation d'où le besoin d'annoter les types. Sinon on le verra au niveau des tests unitaires s'ils sont bien faits.
Donc vraiment, c'est très rare d'avoir besoin de filtrer et surtout ce n'est pas une obligation. Ce n'est pas parce que je fais une fonction foo que je suis obligé de la rendre générique pour tous les types imaginables.
Si en Java tu as le choix entre deux méthodes A et B avec la même signature alors tu peux remplacer l'appel à la méthode A par la méthode B sans problème de compilation. Ça ne fera certainement pas ce que tu voulais à l'exécution...
Bon et bien là c'est pareil (en pire car le type n'est pas précisé donc plus simple de se planter) : si tu n'appelles pas la bonne fonction, on ne peut plus rien pour toi.