RAII en Python - automatique de la destruction au moment de quitter un champ d'application

J'ai essayé de trouver RAII en Python.
L'Allocation des ressources Est d'Initialisation est un modèle en C++ par lequel
un objet est initialisé comme il est créé. Si elle échoue, alors il jette
une exception. De cette façon, le programmeur sait qu'
l'objet ne sera jamais laissé dans un demi-construit de l'état. Python
peuvent le faire beaucoup plus.

Mais RAII travaille également avec les règles de portée de C++
pour assurer la destruction rapide de l'objet. Dès que la variable
pop hors de la pile, il est détruit. Cela peut se produire en Python, mais seulement
si il n'y a aucune externes ou des références circulaires.

Plus important encore, un nom pour un objet existe toujours jusqu'à ce que la fonction qu'il est
en sorties (et parfois plus). Les Variables au niveau du module sera
de rester pour la durée de vie du module.

Je voudrais avoir une erreur si je fais quelque chose comme ceci:

for x in some_list:
    ...

... 100 lines later ...

for i in x:
    # Oops! Forgot to define x first, but... where's my error?
    ...

J'ai pu supprimer manuellement les noms après je l'ai utilisé,
mais qui serait assez moche, et exigent un effort de ma part.

Et j'aimerais qu'il fasse Ce que je veux Dire dans ce cas:

for x in some_list:
    surface = x.getSurface()
    new_points = []
    for x,y,z in surface.points:
        ...     # Do something with the points
        new_points.append( (x,y,z) )
    surface.points = new_points
    x.setSurface(surface)

Python n'certains de portée, mais pas au niveau d'indentation, juste à
le niveau fonctionnel. Il semble stupide d'exiger que je fais une nouvelle fonction
juste à portée des variables afin que je puisse réutiliser un nom.

Python 2.5 est la "avec la" déclaration de
mais cela nécessite que j'ai choisi de mettre en __enter__ et __exit__ fonctions
et semble généralement plus orienté vers le nettoyage de ressources comme des fichiers
mutex et de serrures quel que soit le vecteur de sortie. Il ne permet pas de portée.
Ou ai-je raté quelque chose?

J'ai cherché pour "Python RAII" et "Python portée" et je n'étais pas capable de trouver quelque chose qui
a abordé la question directement et de façon autoritaire.
J'ai regardé sur tous les PEPs. Le concept ne semble pas être traitées
dans Python.

Suis-je une mauvaise personne parce que je veux avoir la portée des variables en Python?
Est-ce tout simplement trop onu-Pythonic?

Je ne suis pas grokking il?

Peut-être que je suis en train de prendre de suite les avantages de la dynamique des aspects de la langue.
Est-il égoïste parfois envie champ d'application forcée?

Je suis paresseux pour vouloir le compilateur/interpréteur
pour attraper ma négligence variable réutilisation des erreurs? Eh bien, oui, bien sûr, je suis paresseux,
mais je suis paresseux dans le mauvais sens?

  • RAII est l'équivalent en Python de with déclaration (en fait, je suis surpris de voir que l'acronyme de ne pas le faire dans la PPE 343 - c'était certainement jeté autour d'un lot dans les discussions). L'élément manquant que vous demandez est anonyme, les règles de portée à partir de C/C++ et non, Python n'a pas de celles (même si vous pouvez trouver le report de la PEP 3150 d'intérêt). C'est complètement indépendant de la RAII question.
  • Merci pour la réponse. Je pensais que PEP 3150 était de répondre à ma question, mais j'ai réalisé qu'il ne dit rien de la suppression de l'espace de noms. C'est purement pour déplacer l'appel de la fonction ci-dessus le code qui obtient des valeurs pour les paramètres de sorte qu'il est plus évident que le code est en train d'accomplir. Ce que je n'aime pas à propos de with est que le nom ne va pas loin, et que je dois passer le code en __exit__ au lieu de __del__. Il est peut-être un habile objet wrapper qui serait del le nom de l'objet et de ne pas exiger que je code un __exit__ fonction? Idéalement, il serait affirmer que l'arbitre était le nombre de 0.
  • même si le refcount > 0, vous pouvez del le nom de l'objet à partir de votre propre champ d'application et de se débarrasser de ce nom - ce qui est totalement distincte de en fait en détruisant l'objet. Par exemple, si un objet a été inséré dans un conteneur, son refcount serait > 0, mais vous pouvez toujours del le nom que vous avez utilisé pour faire référence à l'objet lui-même. Peut-être que c'est une partie de votre confusion - del supprime le nom, pas l'objet sous-jacent. C'est une distinction en Python qu'en C/C++ les gens luttent avec - vous traitez avec des noms et des liaisons de noms, pas les variables/les références qui sont alloc ed et libéré.
InformationsquelleAutor markets | 2011-02-21
  1. 28

    tl;dr RAII n'est pas possible, vous mélangez-les avec la portée, en général, et si vous manquez une des plus étendues que vous êtes probablement écrire du mauvais code.

    Peut-être que je ne comprends pas votre question(s), ou vous n'avez pas obtenir des choses essentielles à propos de Python... tout d'Abord, déterministe de la destruction des objets liés à portée impossible dans une de ces ordures de la langue. Les Variables en Python sont simplement des références. Vous ne voulez pas un malloc " d partie de la mémoire à free'd dès qu'un pointeur vers celui-ci est hors de portée, le feriez-vous? Pratique exception dans certains circonstances, si vous arrive d'utilisation ref compter - mais aucune langue n'est assez fou pour définir l'exacte mise en œuvre dans la pierre.

    Et même si vous avez de comptage de référence, comme dans Disponible, c'est un détail d'implémentation. En général, y compris en Python qui a diverses implémentations pas à l'aide de ref de comptage, vous devriez code comme si chaque objet se bloque jusqu'à ce mémoire.

    Comme pour les noms existants pour le reste de l'invocation de la fonction: Vous peut supprimer un nom de la actuelles ou étendue globale via le del déclaration. Toutefois, cela n'a rien à voir avec le manuel de gestion de la mémoire. Il supprime juste la référence. Qui peut ou peut ne pas arriver à déclencher l'objet référencé à GC avais et n'est pas le point de l'exercice.

    • Si votre code est suffisamment long pour que cela provoque des collisions de noms, vous devez écrire de petites fonctions. Et l'utilisation plus descriptif, moins probable-à-clash noms. De même pour les boucles imbriquées l'écrasement de la boucle de la variable d'itération: je suis encore à rencontrer ce genre de problème, alors peut-être que vos noms ne sont pas suffisamment descriptif ou vous devez tenir compte de ces boucles d'intervalle?

    Vous sont corrects, with n'a rien à voir avec la portée, juste avec le nettoyage déterministe (de sorte qu'il chevauche le RAII dans les extrémités, mais pas dans les moyens).

    Peut-être que je suis en train de prendre de suite les avantages de la dynamique des aspects de la langue. Est-il égoïste parfois envie champ d'application forcée?

    Pas. Décent portée lexicale est un mérite indépendante de la dynamique-/staticness. Certes, Python (2 - 3 assez bien fixé ce) a des faiblesses à cet égard, même s'ils sont plus dans le domaine de la fermeture.

    Mais pour expliquer "pourquoi": Python doit être prudent avec où il commence un nouveau champ d'application en raison sans déclaration disent le contraire, la cession d'un nom en fait un local à l'intime/champ d'application actuel. Donc par exemple, si une boucle for a son propre champ d'application, vous ne pouvez pas facilement modifier les variables en dehors de la boucle.

    Je suis paresseux pour vouloir le compilateur/interpréteur pour attraper ma négligence variable réutilisation des erreurs? Eh bien, oui, bien sûr, je suis paresseux, mais je suis paresseux dans le mauvais sens?

    Encore une fois, j'imagine que accidentel resuse d'un nom (de façon à y introduire des erreurs ou des pièges) est rare et un petit de toute façon.

    Edit: À l'état de ce nouveau aussi clairement que possible:

    • Il ne peut pas être basée sur la pile de nettoyage dans une langue utilisant GC. C'est juste pas possible, par définition: une variable est un de potentiellement de nombreuses références à des objets sur le tas qui ne savent ni se soucient lorsque les variables hors de portée, et toute la gestion de la mémoire se trouve dans les mains de la GC, qui fonctionne quand il veut, pas quand un frame de pile est sorti. Ressources de nettoyage est résolu différemment, voir ci-dessous.
    • Nettoyage déterministe passe par la with déclaration. Oui, il n'a pas d'introduire un nouveau champ d'application (voir ci-dessous), parce que ce n'est pas ce qu'il est. Il n'a pas d'importance, il supprime le nom de l'objet géré est lié n'est pas supprimé - le nettoyage est arrivé néanmoins, ce qui reste est un "ne me touchez pas, je suis inutilisable" de l'objet (par exemple un fichier de flux).
    • Python a une portée par fonction, classe, et le module. Période. C'est comment la langue fonctionne, si vous l'aimez ou pas. Si vous voulez/"besoin" plus fine de portée, diviser le code en plus fine des fonctions. Vous souhaitez peut-être pour les plus fines de portée, mais il n'y a pas - et pour les raisons indiquées plus haut dans cette réponse (trois paragraphes au-dessus de la "Edit:"), il y a des raisons pour cela. Comme lui ou pas, mais c'est comment la langue fonctionne.
    • Merci pour la réponse. Idéalement, je voudrais indiquer une variable doit avoir qu'une portée limitée avec un mot clé comme "auto". Si, à la fin du bloc il y a d'autres référence à elle, alors elle doit lever une Exception. Si non, alors, l'objet doit être immédiatement détruits. Qui devrait être d'accord avec GC, n'est-ce pas? Concernant l'utilisation de petites fonctions: je n'ai pas de temps à consacrer refactoring d'autres peuples de code, et il ne serait pas de résoudre le problème de toute façons, car il peut arriver dans (presque) arbirarily de petites fonctions... c'est juste plus facile à se produire dans de grandes fonctions.
    • Que serait une assez grande caractéristique, cependant, et depuis la suggestion vient d'un programmeur C++ pas vraiment à l'aise avec Python encore... sans oublier que le point de l'ensemble de la GC est de ne pas avoir à s'inquiéter de savoir qui a des références à qui et quand il est sûr de le supprimer (ou plutôt, quand il peut être supprimé par certains gestionnaire de mémoire).
    • Et comme pour les collisions de noms: Vraiment, je (et à en juger par le manque de commentaires sur ce, il semble que je ne suis pas le seul ici) rencontrer ce problème si rarement je les remarque à peine, et si elle se produit ensuite, il y a également un très bon nom pour l'un des deux. Et si la situation devient insupportable, bien désolé, mais vous aurez à trouver un autre champ d'application, soit par la rupture de la fonction ou de trouver une fonctionnalité cachée en Python qui fournit cette...
    • "Si, à la fin du bloc il y a d'autres référence à elle, alors elle doit lever une Exception. Si non, alors, l'objet doit être immédiatement détruit." Ce qui signifierait que vous auriez à exécuter un GC à chaque fois qu'une variable est hors de portée, ce qui n'est pas possible pour toutes les implémentations. Il y a une raison pas de ces ordures de la langue met en œuvre les destructeurs de la même manière qu'en C++ et ce joue dans ce problème ici. RAII est surtout un motif inventé en C++ à cause de ses défauts (je n'ose pas déclarer un grand projet c++ exception sûre si elle n'a pas utilisé RAII)
    • penseriez-vous d'un programme Python est exception sûr si elle n'utilise pas RAII? C'est mon point de vue. Je ne suis pas de questionnement RAII est utile. Delnan semble penser que le RAII est peu utile. Peut-être que je ne suis pas la pensée Pythonic assez, peut-être que je suis accroché à la sécurité de la pile. Mais je pense que c'est presque un outil nécessaire pour le bon déroulement logique et à l'exception de sécurité. Et pourquoi vous devez l'exécuter en GC? Il suffit de vérifier le comptage ref. Vous n'obtiendrez jamais un comptage ref trop bas, qui vous oblige à faire un full GC.
    • Je n'ai pas de regarder dans le code source de moi-même, mais je pense qu'il serait plus facile que de le avec-déclaration, a récemment ajouté. Dans certaines circonstances, vous pourriez vouloir affirmer qu'il n'y a pas de références externes. Si la ressource ne sera pas fermer jusqu'à ce que la ref est mis à zéro, j'ai un programme-correction d'intérêt, en affirmant que. GC est un modèle imparfait pour le comportement que je veux, mais c'est la chose la plus proche que Python offre.
    • Eh bien, que me demandez-vous RAII pour? Pour le nettoyage? C'est ce que with est pour. Parce que les ressources de nettoyage devrait être dans __exit__ ou, si vous êtes une pauvre âme qui n'a jamais entendu parler de contexte, les gestionnaires, dans certains extérieur gérable de ressources. GC est assez bien, par définition, non déterministe, et vous ne serez pas obtenir Python pour effectuer un visage talon tour et re-introduire le manuel de gestion de la mémoire ou de certains légèrement déchargée variante de celui-ci. Travailler avec le langage tel qu'il est ou en utiliser un autre. Que penseriez-vous au sujet des demandes de GC en C++?
    • GC est non déterministe et c'est une bonne chose: c'est bien, je ne dis pas que nous allons changer GC, je me demande si je ne suis pas grokking Pythonic pensée en voulant RAII. Tout le monde semble dire que oui, mais ils ne sont pas à me dire comment je doit penser. Qu'est-ce que le remplacement? __exit__ est un mauvais remplacement, car je veux le nom s'en aller sans un del, et __exit__ n'est pas appelé à l'exception de with. Il pourrait être beaucoup plus simple.
    • Comme je l'ai déjà dit, with est la voie à suivre pour le nettoyage déterministe. Et bien que le nom reste après la with bloc terminé, le nettoyage est effectué et ainsi, vous obtenez le même effet appliqué RAII, mais par d'autres moyens. Ou avez-vous une utilisation abusive du terme RAII et en fait juste voulez plus fine de portée?
    • La plupart du temps je suis à la recherche pour le droit Python mème qui prend la place de la pile C++ basé sur les étendues. Il me semble qu'il pourrait (et devrait) être pris en charge en Python, à moins que je suis en train de réfléchir c'est mal. Je suis intéressé par le nom de la portée et de la ressource de nettoyage, dans une représentation propre. Je vais être choqué si la ligne de fond est que le C++ est un plus propre représentation de ce que Python!
    • Une assez longue réponse et une douzaine de longs commentaires n'ont pas à aller n'importe où. Vous devriez peut-être de modifier la question pour être très précis, comme, avec des exemples. Je ne comprends pas comment les choses que vous avez nommé maintenant se rapportent, ni comment nous n'avons pas répondre.
    • tout à fait raison, nous ne sommes pas n'importe où. Mes premières recherches m'ont montré with mais après la première émotion que j'ai réalisé que ce n'était pas ce que je cherchais. Je suis résigné à Python ayant pas appropriée basée sur la pile de portée alternative (qui inclut le nom). Peut-être que je devrais supprimer RAII de ma question, mais je pense qu'il est une partie intégrante du concept à la question de l'étendue du nom. La question a deux exemples qui tous deux illustrent la question du nom de la variable ne va pas loin. Merci pour l'aide, cependant. Au moins maintenant je sais que je ne suis pas rater quelque chose d'évident.
    • Je pense que vous avez encore de ne pas l'avoir (où "il" est "vous vous posez la mauvaise question" et le "pourquoi c'est une fausse question"). Merci de lire mon montage.
    • Merci pour tous vos efforts sur ce point, mais je crois que je with et ce n'est pas ce que je veux, mais je suppose que c'est le "Pythonic way", qui est une partie de ma question. BTW, ton dernier point semble être contredite par le générateur de champ d'application, et les interprétations de la liste ont leur propre champ d'application en Python 3000 (voir les autres réponses). Les choses semblent être la tendance de mon chemin. Cette invalide également votre premier point, que je ne demande pas la pile mise en œuvre, juste comportement. Disons juste d'accord que je suis coincé dans le C++ état d'esprit et je veux des noms d'aller hors de portée et Python ne pas me rencontrer encore là. Je suis unPythonic. 🙁
    • Oui, générateurs d'une des compréhensions n'y a pas de fuite à la variable d'itération(s) à l'extérieur, mais j'ai glosé sur eux comme ils sont très limitées - un seul ou de quelques variables qui sont utilisées par une seule itération, et n'est pas utilisé pour des effets secondaires (eh bien, c'est l'idiome). Comme pour "basée sur la pile de comportement" - il y a un stack en Python comme dans toutes les autres langues. La seule différence semble vous préoccuper est de savoir comment fréquemment un nouveau champ d'application/frame de pile est commencé.
    • RAII est pas intégrante du concept à la question de l'étendue du nom. C'est une très C++-affichage spécifique. Les anciennes langues n'ont pas les destructeurs et les plus récents, les langues n'ont pas de valeur sémantique.
    • Peut-on vérifier cette réponse est encore correct en 2016? La documentation __del__ dit qu'elle est déclenchée par le nombre de références et non pas par la GC. J'ai aussi giflé ensemble cet exemple de code qui semble montrer que le destructeur être invoqué à la fin de leur portée, même sans GC. repl.il/ClkR Donc semble comme le RAII est tout à fait possible.
    • La réponse tient. Comme je l'ai mentionné (mais pas stressé beaucoup parce que c'est finalement un hareng rouge), dans Disponible vous avez des compteurs refcount et donc dans les cas les plus simples d'obtenir immédiatement le nettoyage. Cependant, c'est un détail d'implémentation (par exemple, PyPy et Jython diffèrent). En outre, comme le [__del__ documentation] mentionne, (1) del ne garantit pas du tout que __del__ est appelé (si il y a d'autres références), et (2) les références circulaires ne sont pas nettoyés par des compteurs refcount seul.

    InformationsquelleAutor
  2. 13

    1. Vous avez raison sur with - il est totalement sans rapport avec la variable de portée.

    2. Éviter les variables globales si vous pensez qu'ils sont un problème. Cela inclut les variables de niveau module.

    3. Le principal outil pour cacher l'état en Python sont des classes.

    4. Générateur d'expressions (et en Python 3 interprétations de la liste) ont leur propre champ d'application.

    5. Si vos fonctions sont suffisamment longtemps pour vous de perdre la trace des variables locales, vous devriez probablement refactoriser le code.

    • Point 5 suggère que Sven n'a rien de mieux à faire de son temps que de refactoriser d'autres personnes de code à chaque fois qu'il est appelé à le toucher. Alors que je compatis avec le sentiment, et j'ai certainement lu beaucoup de livres, je n'ai pas ce luxe au travail.
    InformationsquelleAutor Sven Marnach
  3. 8

    Mais RAII fonctionne aussi avec la détermination de la portée
    les règles de C++ pour assurer le prompt
    la destruction de l'objet.

    Cela est considéré comme sans importance dans la résolution GC langues, qui sont fondés sur l'idée que la mémoire est fongibles. Il n'y a pas de besoin urgent de récupérer la mémoire d'un objet tant qu'il y aura assez de mémoire d'ailleurs d'attribuer de nouveaux objets. Non fongible des ressources comme des descripteurs de fichiers, sockets, et les mutex sont considérés comme un cas particulier d'être traitée spécialement (par exemple, with). Cela contraste avec le C++de modèle qui traite de toutes les ressources de même.

    Dès que la variable pop hors de l'
    pile, il est détruit.

    Python n'a pas de pile variables. En C++ termes, tout est un shared_ptr.

    Python n'certains de portée, mais pas à
    le niveau d'indentation, juste à la
    niveau fonctionnel. Il semble stupide
    exiger que je fais une nouvelle fonction
    juste à portée des variables, donc je peux
    la réutilisation d'un nom.

    Il aussi ne la portée de l'alternateur, de son degré de compréhension (et en 3.x, dans tous interprétations).

    Si vous ne voulez pas tabasser votre for les variables de boucle, ne pas utiliser autant de for boucles. En particulier, c'est l'onu-Pythonic à utiliser append dans une boucle. Au lieu de:

    new_points = []
for x,y,z in surface.points:
    ...     # Do something with the points
    new_points.append( (x,y,z) )

    écrire:

    new_points = [do_something_with(x, y, z) for (x, y, z) in surface.points]

    ou

    # Can be used in Python 2.4-2.7 to reduce scope of variables.
new_points = list(do_something_with(x, y, z) for (x, y, z) in surface.points)
    InformationsquelleAutor dan04
  4. 2

    Fondamentalement, vous utilisez probablement une mauvaise langue. Si vous voulez sane règles de portée et fiable destruction puis coller avec C++ ou essayez de Perl. Le GC débat sur quand la mémoire est libérée semble manquer le point. C'est sur la libération d'autres ressources comme les mutex et les descripteurs de fichiers. Je crois que C# fait la distinction entre un destructeur est appelé lorsque le compteur de référence est mis à zéro et quand il décide de recycler la mémoire. Les gens ne sont pas préoccupés par le recyclage de la mémoire mais ne veulent savoir dès qu'il n'est plus référencé. C'est dommage que Python a un réel potentiel en tant que langue. Mais il est non conventionnelles de délimitation de l'étendue et peu fiables destructeurs (ou au moins la mise en œuvre dépendantes) signifie que l'on est refusé à la puissance que vous obtenez avec C++ et Perl.

    Intéressant le commentaire fait à propos pour l'utilisation d'une nouvelle mémoire si elle est disponible, plutôt que le recyclage des vieux dans le GC. N'est-ce pas juste une façon élégante de dire qu'il perd de la mémoire 🙂

    • Merci pour la réponse, Tony. Je suis d'accord que le fait de ne pas soutenir en Python est regrettable. Curieusement, je ne vois pas pourquoi il ne peut pas être pris en charge. Il semble juste être sucre syntaxique pour tourner une affectation de variable dans un bloc try où il supprime le nom de la enfin, la section. Je n'ai pas encore d'entendre une réponse qui me convainc que c'est mieux comme actuellement implémenté en Python.
    • "Le GC débat sur quand la mémoire est libérée semble manquer le point. C'est sur la libération d'autres ressources comme les mutex et les descripteurs de fichiers. "en C#, Python, JavaScript et Java, ils n'ont pas automatiquement de la gestion des ressources, seulement mémoire GC. C++, PHP, Perl, et même C de GNU avec des attributs a RAII. Je ne comprends pas comment écrire correct code sur ceux GC langues.
    InformationsquelleAutor tony
  5. 2

    Lors du passage à Python après des années de C++, je trouve qu'il est tentant de s'appuyer sur __del__ pour imiter RAII-type de comportement, par exemple, fermer des fichiers ou des connexions. Cependant, il existe des situations (par exemple, modèle observateur tel que mis en œuvre par Rx) où la chose observée maintient une référence vers l'objet, de le garder en vie! Donc, si vous voulez fermer la connexion, avant d'être arrêté par la source, vous n'obtiendrez pas n'importe où en essayant de le faire dans __del__.

    La situation suivante se pose dans l'INTERFACE utilisateur de programmation:

    class MyComponent(UiComponent):

    def add_view(self, model):
        view = TheView(model) # observes model
        self.children.append(view)

    def remove_view(self, index):
        del self.children[index] # model keeps the child alive

    Donc, voici la façon d'obtenir RAII-type de comportement: créer un récipient avec de l'ajouter et de supprimer les crochets:

    import collections

class ScopedList(collections.abc.MutableSequence):

    def __init__(self, iterable=list(), add_hook=lambda i: None, del_hook=lambda i: None):
        self._items = list()
        self._add_hook = add_hook
        self._del_hook = del_hook
        self += iterable

    def __del__(self):
        del self[:]

    def __getitem__(self, index):
        return self._items[index]

    def __setitem__(self, index, item):
        self._del_hook(self._items[index])
        self._add_hook(item)
        self._items[index] = item

    def __delitem__(self, index):
        if isinstance(index, slice):
            for item in self._items[index]:
                self._del_hook(item)
        else:
            self._del_hook(self._items[index])
        del self._items[index]

    def __len__(self):
        return len(self._items)

    def __repr__(self):
        return "ScopedList({})".format(self._items)

    def insert(self, index, item):
        self._add_hook(item)
        self._items.insert(index, item)

    Si UiComponent.children est un ScopedList, qui appelle acquire et dispose méthodes sur les enfants, vous obtenez la même garantie de déterministe de l'acquisition des ressources et de l'élimination que vous êtes habitué à en C++.

    InformationsquelleAutor Jonathan Zrake