Discussion :

[rambc]

Bonsoir,
j'ai découvert un truc qui me paraissait être "mauvais" mais au final qui n'est pas mal du tout. Jusqu'à présent, pratiquant majoritairement de la POO, je n'avais pas besoin de définir des fonctions dans des fonctions comme dans le 1er code ci-dessous proposé par un collègue.

Je préfère malgré tout le 2nd pour des raisons de lisibilité mais je vois tout l'intérêt de cette technique pour notamment cacher de fonctions internes d'un package qui n'ont aucune utilité pour l'utilisateur du dit package.

MA QUESTION. Ceci étant que pensez-vous de cette pratique ? Existe-t-il des effets indésirables ?


CODE AVEC FONCTION DANS FONCTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
def recherche(x, L):
    d, f = 0, len(L)-1
 
    def r(deb, fin):
        if deb > fin:
            return "Elément non trouvé"
 
        t = (deb + fin)//2
 
        if x == L[t]:
            return t
 
        elif x < L[t]:
            return r(deb, t-1)
 
        else:
            return r(t+1, fin)
 
    return r(d, f)
 
 
L = [3, 5, 8, 9, 15, 45, 123, 125]
 
print(recherche(45, L))

CODE SANS FONCTION DANS FONCTION

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
def r(deb, fin):
    global x, L
 
    if deb > fin:
        return "Elément non trouvé"
 
    t = (deb + fin)//2
 
    if x == L[t]:
        return t
 
    elif x < L[t]:
        return r(deb, t-1)
 
    else:
        return r(t+1, fin)
 
def recherche(x, L):
    d, f = 0, len(L) - 1
 
    return r(d, f)
 
x = 45
L = [3, 5, 8, 9, 15, 45, 123, 125]
 
print(recherche(45, L))

[tyrtamos]

Bonjour rambc,

J'ai souvent ce problème de choix avec des fonctions récursives qu'il faut initialiser: la fonction extérieure permet cette initialisation, lance la fonction intérieure, et peut, à la fin, renvoyer des données correctement mises en forme.

Je ne me méfie de cette forme seulement pour une raison: j'ai déjà rencontré des problèmes avec un traitement de code python, mais je ne me rappelle plus lequel (py2exe? cx_freeze? cython?). De ce fait, à titre préventif, je programme souvent comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
def _mafonction(...):
    ...
 
def mafonction(...):
    ...
    x = _mafonction(...)
    ...

La différence est qu'il ne faut pas oublier de paramètres à passer. En effet, dans la forme compacte (fonction de fonction), les variables locales de la fonction extérieure sont des variables globales pour la fonction intérieure.

Mais par ailleurs, la forme compacte permet de faire des décorateurs plutôt élégants, et pour eux, je ne cherche pas à faire autrement.

A titre d'exemple, voilà un décorateur qui affiche le temps d'exécution de la fonction décorée (python 2.7) exécutée n fois:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import functools
import time
 
def tempsexec(n=1):
    """ decorateur pour calculer le temps d'exécution de n appels """
    def _decorateur(fonc):
        @functools.wraps(fonc)
        def appelfonc(*args, **kwargs):
            t = time.clock()
            for i in xrange(0,n):
                result = fonc(*args, **kwargs)
            t = time.clock()-t
            print u"Temps d'exécution: %.7f s" % (t,)
            return result
        return appelfonc
    return _decorateur

Exemple d'application pour le temps total de 100 exécutions de la fonction 'calcul':

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
@tempsexec(100)
def calcul(a,b,c):
    ...
    ...
 
print calcul(50,51,52)

Affichage:

Temps d'exécution: 1.4949730 s
2071046250

[marco056]

Avec Python3, j'ai repris le code précédent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
import functools
import time
 
def tempsexec(n=1):
    """ decorateur pour calculer le temps d'exécution de n appels """
    def _decorateur(fonc):
        @functools.wraps(fonc)
        def appelfonc(*args, **kwargs):
            t = time.clock()
            for i in range(0,n):
                result = fonc(*args, **kwargs)
            t = time.clock()-t
            print ("Temps d'exécution: %.7f s" % (t,))
            return result
        return appelfonc
    return _decorateur
 
@tempsexec(100)
def pair1(m):
	el = range(0,m)
	paire=[]
	for np in el:
		if np%2==0:
			paire.append(np)
	return(paire)
 
print(pair1(20))

Et j'obtiens 0 dans tous les cas...
J'ai loupé quelque chose ?

Temps d'exécution: 0.0000000 s
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]

[tyrtamos]

Bonjour marco056,

Légèrement inquiet, j'ai repris ton code en copier-coller sous Python 3.2, et: ça marche!

Cela donne:

Temps d'exécution: 0.0005489 s
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]

Essaie avec une fonction simple comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
@tempsexec(100)
def calcul():
    time.sleep(0.1)
    return "fin"

Qui devrait donner environ 10s.

[fred1599]

Bonjour,

Cela s'appelle closure, ce type de syntaxe est utilisé pour les décorateurs, et souvent pour éviter les variables globales, où l'on préfèrera les variables locales.

[wiztricks]

MA QUESTION. Ceci étant que pensez-vous de cette pratique ? Existe-t-il des effets indésirables ?

Le comportement de la fonction "r" n'est prédictible qu'appelée par "recherche". Impossible de la tester "indépendamment" sans faire le boulot d'initialisation fait par "recherche".
Cette dépendance entre "recherche" et "r" est quand même mieux traduite via un "nesting" que par le passage de variables globales.

Cela s'appelle closure, ce type de syntaxe est utilisé pour les décorateurs, et souvent pour éviter les variables globales, où l'on préfèrera les variables locales.

rambc ne nous parle que de "nested functions".
Une fonction n'est pas un objet: sa duree de vie est réduite aux moments ou l’interpréteur l’exécute.
Une "closure" a la même durée de vie que d'autres objets: zero reference => destruction par le GC.

rambc aurait pu écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
def recherche(x, L):
    def r(deb, fin):
        if deb > fin:
            return "Element non trouve"
        t = (deb + fin)//2
        if x == L[t]:
            return t
        elif x < L[t]:
            return r(deb, t-1)
        else:
            return r(t+1, fin)
    return r
x = 45
L = [3, 5, 8, 9, 15, 45, 123, 125]
print('use closure ', recherche(45, L)(0, len(L)))

Dans ce cas, recherche retourne un objet "function" et aura stocke (x, L) dans le locals() construit a son appel. La référence a la fonction "r" scotche ce locals() "englobant".
Avec des "class" on pourrait écrire cela ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class recherche:
    def __init__(self, x, L):
        self._args = x, L
    def __call__(self, deb, fin):
        x, L = self._args
        if deb > fin:
            return "Element non trouve"
        t = (deb + fin)//2
        if x == L[t]:
            return t
        elif x < L[t]:
            return self(deb, t-1)
        else:
            return self(t+1, fin)
 
x = 45
L = [3, 5, 8, 9, 15, 45, 123, 125]
print('use instance dict', recherche(45, L)(0, len(L)))

La syntaxe d'appel ne change pas.
C'est juste la construction de l'objet retourne (un callable) par "recherche(x, L)" qui est écrite (et réalisée) autrement.

- W

[marco056]

Bonjour marco056,
Légèrement inquiet, j'ai repris ton code en copier-coller sous Python 3.2, et: ça marche!

Étrange !
Chez moi, le code suivant donne cela :

Temps d'exécution: 0.0000000 s
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
Temps d'exécution: 0.0100000 s
fin

Code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#! /usr/bin/env python3
# -*- coding: utf8 -*-
 
import functools
import time
 
def tempsexec(n=1):
    """ decorateur pour calculer le temps d'exécution de n appels """
    def _decorateur(fonc):
        @functools.wraps(fonc)
        def appelfonc(*args, **kwargs):
            t = time.clock()
            for i in range(0,n):
                result = fonc(*args, **kwargs)
            t = time.clock()-t
            print ("Temps d'exécution: %.7f s" % (t,))
            return result
        return appelfonc
    return _decorateur
 
@tempsexec(100)
def pair1(m):
	el = range(0,m)
	paire=[]
	for np in el:
		if np%2==0:
			paire.append(np)
	return(paire)
 
print(pair1(20))
 
@tempsexec(100)
def calcul():
    time.sleep(0.1)
    return "fin"
 
print(calcul())

[wiztricks]

Salut,

RTFM

Sur Linux, time.clock ne retourne pas l'elapsed time mais le temps CPU consomme par le process. time.sleep(0.1) ne consommant pas grand chose => le résultat est "petit".

Sur Windows, time.clock retourne l'elapsed time 100 * 0.1 ~ 10s.
A partir de Python 3.3, time.clock est "deprecated", il est recommande d'utiliser time.process_time a la place.
Et ça devrait être "consistant" sur tous les OS.

- W

[tyrtamos]

@marco056

Jusqu'à présent, j'étais sous Windows.

Je viens d'essayer sous Linux (Mint15) avec Python 2.7 et Python 3.3: je trouve la même chose que toi dans les 2 versions. Le problème vient donc de la différence d'implémentation de time.clock entre les 2 OS.

Par contre, ça marche en remplaçant time.clock() par time.time().

Bizarre, bizarre...

[grillé par wiztricks]: merci pour l'explication! Je vais faire les modifs qui s'imposent.

[marco056]

@marco056

Jusqu'à présent, j'étais sous Windows.

Je viens d'essayer sous Linux (Mint15) avec Python 2.7 et Python 3.3: je trouve la même chose que toi dans les 2 versions. Le problème vient donc de la différence d'implémentation de time.clock entre les 2 OS.

Par contre, ça marche en remplaçant time.clock() par time.time().

Bizarre, bizarre...

[grillé par wiztricks]: merci pour l'explication! Je vais faire les modifs qui s'imposent.

OK, merci.
Je suis en ce moment sous linux, cela vient donc de là.

[wiztricks]

@[B][grillé par wiztricks]: merci pour l'explication! Je vais faire les modifs qui s'imposent.

Sous Linux, time.time() est la moins mauvaise solution pour les versions antérieures a 3.3. Le soucis étant sa précision bien inférieure au time.clock (sous Windows).

- W

[tyrtamos]

[coup_de_gueule]
Oui, mais ce n'est pas chouette de la part de Python.

Sous Linux, ça ne marche pas sous Python 2.7, mais clock n'est pas obsolète, et ni perf_counter() ni process_time() n'existe: la seule solution est donc d'utiliser time()? Mais avec time(), on a l'activité de l'ordinateur, et pas seulement la fonction mesurée.

Et sous Python 3.3, il faut utiliser soit perf_counter(), soit process_time() selon la machine: on fait quoi pour choisir dans un programme qu'on transporte: on joue aux dés?

Faut-il maintenant un "sniffeur" à l'exécution pour sélectionner la fonction qui marche?
[/coup_de_gueule]

[marco056]

Ce n'est pas bête le coup du sniffeur :
Qqchose comme cela ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
import os
import sys
import platform
 
# print(os.name)
# print(os.uname())
if os.name == "posix":
	if platform.system() == "Linux":
		print("linux")
	else:
		print("Mac")
else:
	print("Wndows")
 
print (sys.platform,"=>", end=" ")
if sys.platform == "win32":
    print("Windows")
elif sys.platform == "mac":
    print("Mac")
elif sys.platform == "linux":
	print("Linux")
else:
	print("Inconnu")

[rambc]

Merci pour toutes ces réponses.

Reste à voir si j'aurais besoin un jour ou l'autre des closures... Pour les fonctions imbriquées, je ne m'en servais que pour les décorateurs.

[tyrtamos]

Bonjour,

Finalement, on n'aura peut-être pas besoin d'un "sniffeur" pour savoir quel fonction de mesure des temps fonctionne: Python a déjà ça avec le module "timeit".

Ainsi, on remplace dans les codes ci-dessus "time.clock()" par "timeit.default_timer()", et c'est Python qui se débrouille pour que ça marche (Windows ou Linux, Python 2.7 ou Python 3.3. Ok aussi sous Mac OS X 10.8.5 avec Python 2.7).

Bon. Je ne suis pas sûr qu'on ait les microsecondes dans tous les cas, mais au moins, ça ne raconte pas n'importe quoi.

[wiztricks]

Reste à voir si j'aurais besoin un jour ou l'autre des closures... Pour les fonctions imbriquées, je ne m'en servais que pour les décorateurs.

Les decorateurs retournent des callables. Ecrits sous forme de nested functions, ce sont des "closures".
- W