Comments on: State machine en Python en l’absence d’algos récursifs bénéficiant de tail call optimisation

By: ast

ast — Mon, 14 Mar 2016 17:04:06 +0000

Juste un petit détail, il y a:

def etat1(a, b, c):

print "Etat 3"

dans les 2 codes avec/sans TCO

au lieu de print "Etat 1"

By: Sekun

Sekun — Tue, 28 Apr 2015 08:42:51 +0000

Merci pour l’article, j’avais utilisé ceci pour faire de la récursivité terminale en python: http://metapython.blogspot.be.

Usage à la fin pour la fonction factorielle:

@tailrecursive


def tail_fatorial (n, a=1):
if n == 1:
return a * 1

return tail_fatorial(n -1, n * a)

By: OPi

OPi — Wed, 13 Feb 2013 18:20:27 +0000

Direction illico dans mes bookmarks :-)

By: Teocali

Teocali — Sat, 18 Aug 2012 01:30:04 +0000

J’adore le titre du post…

Quoi, la machine a etat non recursive ? Oui, j’aime beaucoup aussi.

By: Sam

Sam — Fri, 10 Aug 2012 13:42:42 +0000

Une petit lib sympas pour faire des states machines bien propres:

https://github.com/rbarrois/xworkflows

By: Sam

Sam — Thu, 02 Aug 2012 13:49:00 +0000

Je le met là car on ne sait jamais:

>>> import sys
>>> sys.getrecursionlimit()
1000
>>> sys.setrecursionlimit(100000)
>>> sys.getrecursionlimit()
100000

Pour les fans de récursions.

By: Sam

Sam — Thu, 26 Jul 2012 16:56:15 +0000

@gael:

Ouai comme le précise LB, la limite est une question d’implémentation. Vous avez essayé Stackless ? Je n’ai aucun retour de mise en prod et je suis curieux d’avoir un feedback.

En fait j’avais pas réaliser que la TCO, c’est un peu comme VI/Emacs, tab/spaces, libre/proprio… C’est une grosse guerre de religion. Mais au final, ce qui est rassurant, c’est que généralement tous ceux qui sont assez barrés pour s’engager dans le débat sont en général de bons professionels. Le dev lambda (sans jeu de mot), il s’en branle.

By: Sam

Sam — Thu, 26 Jul 2012 16:52:30 +0000

Oui, c’est une forme de TCO à la main, avec une différence: python ne supprime pas d’entrées arbitrairement dans la stack, ce qui est fort chouette pour le débuggage.

Par ailleurs, je pense que l’entêtement de guido tient du fait qu’il veut garder le style de Python orientée d’une certaine façon. Il y a des tas d’autres très bons langages qui permettent de faire autrement, donc pour lui, il n’y a pas de raison de transformer Python en un de ses langages.

Je trouve que ça se tient: c’est une bonne chose qu’il y ai différents styles et différentes capacités pour chaque techno. Une techo fourre tout qui fait tout ce que font les autres ne marchent jamais.

Bon par contre, moins élégant que la version récursive, je veux bien. Mais quand même plus élégant qu’une exploration de stack frame hein :-) Explicit is better than implicit, tout ça.

By: Gael

Gael — Thu, 26 Jul 2012 16:27:18 +0000

Avec Stackless Python on peut faire un carton et franchir la barre des 1000 entrées ;)

By: LB

LB — Thu, 26 Jul 2012 16:00:26 +0000

Il s’agit ni plus ni moins de faire du TCO à la main. ça marche mais c’est pas très convaincant. (On peut faire de même avec un décorateur qui explore les stackframes et fait ce qu’il faut).

( A noter aussi qu’il s’agit d’un limitation de l’interpréteur CPython, je ne suis pas sur que Pypy ou Jython aient les mêmes limitations. )

L’intégrer à l’interpréteur serait plus élégant mais Guido est contre malgré la démonstration que ce serait sans véritable inconvénient. Il est tétu le bougre. Il n’aime pas la programmation fonctionnelle et vu que la TCO favorise ce type de codage, ce n’est pas très étonnant.

La simplicité de l’interpréteur CPython est à la fois la meilleur chose et le plus grand frein (GIL, TCO), etc. Il suffit de voir LuaJit pour comprendre que d’autre choix sont possible…