C’est comme pour les conditions! if elif else.
j’aimerai bien savoir qui blinde son code et met dans le else les cas non étudié lors de la conception du programme.

Genre exemple simple: J’ai une ligne vide dans un fichier csv si celle-ci est vide je renvoi pas une erreur je l’ignore mais je le spécifie dans la doc comme étant un cas volontairement ignoré.

Programmer c’est aussi expliquer les limites d’un programme! Et donc la doc c’est important tous comme un bon modèle.

Au moins on le sais si c’est Null ben c’est Null.

“objections tout à fait valide//s/”

J’aime bien les différentes façons dont les langages de programmation expriment le vide. Ça amène parfois des concepts bizarres.
*void rien = NULL;
Tout ça …

try:
…
except:
pass

sans que ça pose problème non ? Alors pourquoi le null object serait problématique en lui même ?

Je crois que mon tort c’est de n’avoir pas posté un example d’utilisation concret.

C’est complètement différemment

Mock se comporte exactement comme tu le décris dans ton objet NULL. Là pour le coups, non ce n’est pas différent.

mais pour renforcer le duck typing.

L’intêret du duck typing c’est de se dire “Si il vole comme un oiseau, c’est que c’est peut-être un oiseau”, d’où :

>> bird.fly()
"I'm flying !"

Donc, si l’objet ne vole pas , je veux qu’il se casse la gueule, pas lui greffer des prothèses pour qu’il vole 5m et qu’il se casse la gueule après pour faire encore plus de dégats.

>> car.fly()
AttributeError: 'Car' object has no attribute 'fly'

Y’a que chez Harry Potter que les voitures ça vole, et même dans ce monde merveilleux, elle finit par se ramasser lamentablement dans un sol cogneur.
Autant qu’elle ne commence même pas à voler, ça aurait éviter bien des problèmes.

D’ailleurs, c’est souligné dans l’article de wikipedia sur le duck typing

“If the object does not have the methods that are called then the function signals a run-time error”

On s’attend bien à avoir une erreur au runtime, pas qu’elle soit masquée.

(Cela dit, ce n’est pas parce que je ne suis pas d’accord sur ce point d’utilisation, que de manière général , je ne suis pas satisfait de votre boulot de blogeur python. J’en apprend régulièrement avec vous, continuez à écrire, c’est vraiment chouette de vous lire :))

Comme try/except utilisé pour la gestion des flux n’est pas une aberration en Python.

Il ne faut pas être dogmatique, ça élimine des opportunités de progression.

Utilisez le bon outil pour le bon travail, je ne cesserai de le répéter.

ouais sauf que là à mon sens, c’est vraiment pas le bon cas d’utilisation.

Il existe une bibliothèque qui intègre déjà se pattern: mock. Sauf que ce n’est absolument pas pour “économiser des if”. C’est principalement pour créer des “bouchons” avec l’environnement extérieur (ou pas) et ISOLER le code pour faire des tests unitaires.

Utiliser se pattern pour enfouir des erreurs, c’est absolument à proscrire.