Bonjour à tous - Je viens ici demander une aide suite à un problème qui me turlupine. A force de chercher, j'ai réussi à ramener le problème à un exemple tout simple qui servira de démo facilement compréhensible
 
Je dois gérer un objet texte. A cet objet y vont s'adjoindre diverses méthodes me permettant de récupérer des infos sur ce texte comme nb lignes, de mots, etc.
A un moment donné, je dois renvoyer un paragraphe du texte. Je me dis en moi-même "un paragraphe étant un mini-texte, si je renvoie une nouvelle instance de mon objet ne contenant que ledit paragraphe, cette instance bénéficiera de toutes les méthodes utiles (nb de lignes, de mots, etc).
 
Mais c'est là que ça se corse. Voici un petit exemple tout simple montrant le problème. Pour simplifier, j'ai juste créé un objet qui stocke un tableau de nombres et créé une méthode "sort" qui renvoie un nouvel objet contenant le tableau trié

#!/usr/bin/env python 
# coding: Latin-1 -*- 
 
class cGestion: 
    def __init__(self): 
        print "init: %s" % repr(self) 
        self.tab=[] 
 
    def __del__(self): 
        print "del: %s" % repr(self) 
        del self.tab[:] 
        del self.tab 
 
    def __str__(self): 
        return "[%s]: %s" % (repr(self), self.tab) 
 
    def append(self, k): 
        self.tab.append(k) 
 
    def sort(self): 
        n=cGestion() 
        for k in self.tab: 
            n.append(k) 
        n.tab.sort() 
        return n 
 
# Création élément de base 
base=cGestion() 
base.append(2) 
base.append(1) 
base.append(0) 
print "\nbase: ", base 
 
# Test 1: copie triée de l'objet de base - la copie est mémorisée 
cp=base.sort() 
print "\ntest 1:" , cp, cp.tab 
del cp 
 
# Test 2: affichage juste d'une instance triée 
print "\ntest 2:", base.sort() 
 
# Test 3: affichage d'un élément de l'instance triée 
print "\ntest 3:", base.sort().tab

 
A la base, je crée mon objet. Les affichages sont ok
Au test 1, je récupère une copie triée de mon objet. Aucun souci
Au test 2, j'affiche juste la copie triée de mon objet mais ne l'ai pas sauvegardée. Cependant aucun souci
Au test 3, là j'affiche le tableau stocké dans la copie au moment de la copie et là, je me rends compte que le destructeur a déjà fait son office et le tableau est vide.
 
Ce qui est intéressant, c'est que si dans le destructeur on supprime le nettoyage du tableau (del self.tab[:]), là tout marche bien. Je sais que Python possède une gestion de la mémoire et que je ne devrais pas me préoccuper de libération de mon tableau interne mais je suis issu du C et c'est plus fort que moi. Si mon constructeur crée un élément, mon destructeur supprime l'élément.
 
Quelqu'un aurait un conseil à me donner ?
 
Merci

Le comportement est tout à fait normal : dans le test 3, tu n'as aucune référence mémorisée vers l'objet rejeté par base.sort(). Quand tu affiches base.sort().tab, Python appelle automatiquement le destructeur vers l'objet rejeté par base.sort() (puisqu'aucune référence n'est faite vers cet objet), et comme ton destructeur supprime l'élément tab de cet objet, par extension, il supprime tout avant que tu l'affiches.

 
Yo merci d'avoir répondu si vite. Tu décris effectivement ce dont je me doutais (surtout que je vois le "del" apparaître avant l'affichage du "test3" ). Mais comment faire alors pour
1) rester propre niveau gestion de la mémoire
2) pouvoir récupérer quand-même mon "base.sort().tab"
???

1) Ne pas gérer la mémoire toi-même quand ce n'est pas nécessaire.  
2) Respecter le point 1 ^^
 
 
Définir un del sur ton objet n'ajoute rien pour le garbage collector, vu que tu ne fais (à peu de choses près) que redéfinir un comportement par défaut (la variation faisant que ça ne marche pas ici). Si tu souhaites libérer de la mémoire, une simple suppression de la variable référençant cet objet est suffisante pour avoir un nettoyage "en cascade" si nécessaire, traité par le garbage collector automatiquement au moment le plus opportun.

Ca retire des choses même. Ca empêche le détecteur de références circulaires de bosser correctement par exemple, un cycle contenant un objet (ou plus) ayant une méthode __del__ définie ne sera pas détecté, donc pas supprimé, et devra être intégralement nettoyé manuellement.

Il ne faut jamais définir de __del__ quand on est pas certain que c'est exactement ce dont on a besoin (et globalement c'est uniquement le cas pour des ressources rares: handlers de fichiers ou de sockets, connections, ...).

 
Et ce garbage est efficace ? Imaginons que je fasse une boucle style

for i in range(1000):
    a=cGestion()
    ...

 
Sera-ce plus efficace que

for i in range(1000):
    a=cGestion()
    ...
    del a

???

Le GC tourne dans les deux cas, il n'y a aucune raison pour qu'il y ait une différence significative, et la 2e version a une instruction (del) de plus que l'autre

>>> class A(object):
    def __init__(self):
        self.tab = []
 
        
>>> def testref():
    for i in range(1000):
        a = A()
 
        
>>> def testdel():
    for i in range(1000):
        a = A()
        del a
 
        
>>> from timeit import Timer
>>> t1 = Timer('testref()', 'from __main__ import testref')
>>> t2 = Timer('testdel()', 'from __main__ import testdel')
>>> t1.repeat(number=10000)
[11.701371822396425, 11.629359038648772, 11.613105855632483]
>>> t2.repeat(number=10000)
[11.716563138611193, 11.681633000842297, 11.773158599766163]
>>>

 
Faut arrêter les tentatives de microoptimisation à la con dans ce genre, surtout quand tu ne connais pas le runtime et que tu n'as aucune évidence d'un problème de perf (sans même parler de ne pas savoir où est le problème s'il y en a un)

Et accessoirement, le __del__ qui ne sert à rien a clairement un impact fort sur ce microbench à la con (dans une vraie application il serait probablement invisible) dans la mesure où le runtime doit appeler une fonction Python (alors que la suppression d'origine se fait intégralement en C) et exécuter un slice et deux del à l'intérieur:

>>> class B(object):
    def __init__(self):
        self.tab = []
    def __del__(self):
        del self.tab[:]
        del self.tab
 
        
>>> def testrefB():
    for i in range(1000):
        b = B()
 
        
>>> def testdelB():
    for i in range(1000):
        b = B()
        del b
 
        
>>> t3 = Timer('testrefB()', 'from __main__ import testrefB')
>>> t4 = Timer('testdelB()', 'from __main__ import testdelB')
>>> t3.repeat(number=10000)
[19.552072400263171, 19.476673152593378, 19.429103419568719]
>>> t4.repeat(number=10000)
[20.073180809292751, 20.089330068486333, 20.225080003184758]
>>>

(c'est exactement le même code qu'au dessus, j'ai juste rajouté ton __del__ dans la classe)

Non tu ne comprends pas. Je ne cherche pas à optimiser, je cherche juste à être certain que tout ce que j'alloue en mémoire est bien libéré une fois que ce n'est plus utile. Je t'ai dit que j'étais issu du C (et aussi du C++). Si je crée une méthode "__del__", je peux contrôler (print) qu'elle est bien appelée lorsque j'appelle mon del <objet>. Si je ne la crée pas, je ne vois rien et ça, ça me gène.

Python a un GC, le GC se démerde tout seul, tant que tu n'as pas de problème de mémoire ne te préoccupes pas de ça

Et accessoirement, del ne supprime rien, il décrémente le refcount de l'objet de 1, donc si tu pars avec l'idée que c'est équivalent à free/delete t'as déjà tout faux

Idem pour définir __del__, ça se fait pas dans un langage à GC, sauf si tu as une ressource rare qui doit impérativement être relachée (fichier, connection db) et encore (en 2.5+ on passera par un context manager pour ce genre de trucs)

Arf ok
 

Merci pour tout.