Salut, j'ai pour habitude de programmer en C, C++, java parfois. Parfois dans d'autres langages. Dans tous les cas, on m'a toujours dit, et j'ai toujours fait la chose suivante : donner des gardes-fous aux fonctions.

Par exemple si une fonction effectue à un moment une division par un nombre N susceptible de valoir 0, quel que soit le langage, je met une condition du type if(N == 0) ... et je gère ce qu'il faut faire, mais je ne laisse pas la division par 0 se faire.

Là, je suis le tuto du SDZ (oui, oui, je sais ce que vous pensez) sur Python, et que vois-je ?

Ici : http://www.siteduzero.com/informatique/tutoriels/apprenez-a-programmer-en-python/les-fonctions-a-vous-de-jouer

La phrase : "En Python, on préférera mettre un commentaire en tête de fonction ou une docstring, comme on le verra ultérieurement, pour indiquer que max doit être positif, plutôt que de faire des vérifications qui au final feront perdre du temps. Une des phrases reflétant la philosophie du langage et qui peut s'appliquer à ce type de situation est « we're all consenting adults here » (en français, « Nous sommes entre adultes consentants »). Sous-entendu, quelques avertissements en commentaires sont plus efficaces qu'une restriction au niveau du code."

Vous me confirmez ça? Je vais être amené à coder pour d'autres gens dans des branches scientifiques. Si je le fais en Python, et sous prétexte que c'est en Python, alors tous les garde-fous tombent ?

Si tu veux mon avis, tu te plantes autant que le site du zéro sur le sujet.

C'est idiot de vouloir mettre à tout prix des gardes fous à toutes les fonctions. Tout comme c'est idiot de dire que la philosophie de <insérer ici un langage> nous met à l'abri de la connerie humaine.

La vérité, c'est que faire des tests est couteux. Parfois on préfère payer le prix en échange de la garantie que l'utilisateur ne pourra pas faire de bêtise avec notre code, parfois non. Et ceci est complètement indépendant du langage.

Je conçois que faire des tests est couteux, mais :

-tester une proposition de complexité c avant de lancer un algorithme de complexité C > c, ça vaut le coup, non ?

-parfois la performance n'est pas requise

Donc je reste étonné.

C'est avec ce raisonnement qu'on se retrouve avec un firefox qui met toujours 10s à se lancer, comme en 2005... sauf qu'en 2005 ma bécanne était 4 fois moins puissante que celle que j'utilise aujourd'hui.

N'oublie pas que :
1. il y a complexité d'une part, et temps d'exécution d'autre part. Il arrive qu'un algorithme cubique mettre en pratique un temps quadratique à l'exécution, simplement parce l'opération de base de la partie quadratique est 100 fois plus lente que celle de la partie cubique.
2. faire un test, ça casse le pipeline au niveau de ton CPU. En l'absence d'un compilateur avec un bon prédicteur de saut pour limiter cette cassure, un test coûte très cher ( >= 100 fois une addition).

Ah ok, je savais pas ça pour le point 2. Merci !

"C'est avec ce raisonnement qu'on se retrouve avec un firefox qui met toujours 10s à se lancer, comme en 2005... sauf qu'en 2005 ma bécanne était 4 fois moins puissante que celle que j'utilise aujourd'hui. "

A quoi ce serait du selon toi?

Firefox reste mon navigateur par défaut, j'y suis tout simplement accro, mais j'utilise également Chrome et c'est vrai qu'au niveau du temps de lancement... Y-a pas photo.

une proposition pour faciliter la programmation par contrat avait été proposée et mise de coter: http://www.python.org/dev/peps/pep-0316/

ici tu devrais éviter ce genre de test et laisser l'utilisateur le faire lui même si il en a besoin. dans un python fidèle, il utilisera un try/except qui est plus rapide qu'un if si l'exception n'est pas attrapée.

Personnellement, j'aime bien une approche multiple du probleme du contrat de fonction. Si c'est de la logique interne de l'application, un truc comme assert devrait faire l'affaire. Ca reste actif pendant le debug, mais saute a la compilation en mode release. Si c'est un test de donne utilisateur, alors il faut laisser ce test en release.