Mais tant qu’à nager dedans : lazy est présent dans ruby depuis la v2.

La nouvelle méthode lazy des Enumerable ?

Ça revient aux générateurs de Python, c’est une manière d’avoir un comportement paresseux, mais ça n’est pas applicable à autre chose qu’aux itérables (énumérables en ruby).

On est ici dans l’idée d’un opérateur lazy qui pourrait s’appliquer à toute expression.

Et pis je parlais d’opérateur ternaire pour ||= , ou de &&=. 1 condition à gauche , une condition à droite, laquelle deuxième condition s’avère être une affectation. 2 opérations, 3 opérandes, un opérateur. C’est bien un opérateur ternaire ça, non ?

Je vois bien les deux opérations (résumées en un seul opérateur), et on peut tirer par les cheveux pour faire apparaître 3 opérandes (dont un dupliqué) en disant que a ||= b est équivalent à a = a || b, mais ça reste pour moi un opérateur binaire.

Mais tant qu’à nager dedans : lazy est présent dans ruby depuis la v2.

Et pis je parlais d’opérateur ternaire pour ||= , ou de &&=. 1 condition à gauche , une condition à droite, laquelle deuxième condition s’avère être une affectation. 2 opérations, 3 opérandes, un opérateur. C’est bien un opérateur ternaire ça, non ?

Quant à return je nage pas, je coule….

Accepter un callable pour absolument tout que potentiellement plus tard tu veux permettre d’injecter peut être un travail énorme, et surcharger le code. En général on le fait au fur et à mesure que l’API muri. lazy permet en attendant de faire le bouche trou.

L’exemple typique qui a lancé la discussion sur la mailing list est le module de logging:

log.message(‘Ceci est un %(bar)s’, {‘bar’: foo()})

Le problème de ça c’est que quoi qu’on fasse on doit appeler foo(), et si c’est un appel long, chaque appel de log est long. Mais si on décide de désactiver ce log level, on voudrait que les messages ne s’appliquent pas.

Idéalement, il aurait fallut que l’API de log accepte un callable en second paramètre. Néanmoins ce n’est pas le cas, et comme l’API est dans la lib standard, elle ne va pas changer de si tôt. Lazy permettrait de toujours s’en sortir dans des cas comme ça.

D’une manière générale c’est aussi un shortcut agréable. Je peux m’imaginer en train de scripter et me dire “je vais dropper des lazy” plutôt que de me faire chier à mettre des callback pour un code qui sera de toute façon jetable.

T’as 100% raison.

J’ai très mal lu, en fait j’ai sauté deux paragraphes…J’ai été déconcentré … Toutes mes excuses, je n’ai pas vraiment relu avant d’envoyer le commentaire… C’était pour la bonne cause (la déconcentration).

Ca m’apprendra à m’entêter quand on essaie activement de me déconcentrer…

Ce que tu évoques en premier correspond aux shortcuts évoqués plus haut dans l’article, qui permettent de faire des expressions conditionnelles avec les mots-clefs and et or (qui restent des opérateurs binaires et non ternaires, ils ne prennent que deux opérandes).

Quant au return, je pense que tu n’as pas compris le sens du mot « paresseux » dans « évaluation paresseuse ».

Il ne s’agit pas au développeur d’être paresseux, mais de permettre d’évaluer une expression le plus tard possible.

Au passage, le mot-clef return optionnel est loin d’être un avantage.

L’un des intérêt c’est qu’une fois systématisé,on ne calcule que ce dont on a besoin (ou presque).

Et ça offre son lot de surprises agréables.

En particulier du point de vue de l’écriture du code.

J’essaie d’illustrer en français :

condition A ET condition B.

=> Si A est faux, pas la peine d’évaluer B, je sais déjà quoi retourner..

Avec un minimum de rigueur, on peut économiser quelques calculs coûteux totalement inutiles.

variable_a OU = 5

En étant “paresseux” : si “variable_a” vaut false, pas la peine d’évaluer l’opérande de droite.

En ruby, seuls nil et false sont évalués comme étant “faux”. Une variable qui n’a pas été affectée vaut nil.

Donc je n’évalue la partie de droite QUE si variable_a n’a pas été affectée. Auquel cas, j’affecte la valeur 5 à variable_a.

Au passage, ça me fait furieusement penser à un opérateur ternaire… sifflote

Quant au ‘return’ lui même : en ruby, l’évaluation paresseuse est quasi systématique.

Quand je rencontre un bloc qui dit “variable_a”, j’évalue ‘variable_a’.

Tant qu’à évaluer, autant retourner la valeur, non ?

En ruby, la dernière valeur évaluée, c’est la valeur de retour de la fonction. Parce que…tant qu’à faire d’être paresseux…

Z’imaginez le nombre de fonction où ça vous évite d’écrire return ?

Le nombre de raccourcis que ça offre ?

Bref, j’espère sincèrement que ça se généralisera.

def somme(a,b):
    print("coucou")
    return a+b

truc = lambda : somme(1,1)

print("hello")
print(truc())

=>

hello
coucou
5

Il n’y a donc rien d’étonnant que Python continue d’évoluer et s’inspire de l’expérience des langages contemporains pour s’améliorer. C’est un bon moyen de ne pas devenir obsolète sans avoir à implémenter des features expérimentales à l’avenir incertain.

Comme d’habitude, la force de Python n’est d’être le meilleur nul part, mais très bon partout.