Que ce soit absolument nécessaire n'est pas la bonne question à poser. La question est de savoir si c'est une bonne idée.
En règle générale dans la programmation, vous devez éviter de faire des choses étranges et utiliser le meilleur outil pour le travail . Si quelque chose a un moyen explicite de libérer des ressources, il suffit de rendre la version explicite et d'en finir avec:
with arcpy.da.UpdateCursor(fc,fields) as cursor:
d = {k: v for (k,v) in cursor}
Ce que vous ignorez peut-être, c'est que la with
clause invoque en fait une logique supplémentaire. Une with
clause nécessite un gestionnaire de contexte, qui doit avoir une méthode __enter__
(invoquée lorsque le bloc est entré) et __exit__
(invoquée lorsque le bloc est quitté). En particulier, la __exit__
méthode est invoquée indépendamment du fait qu'une exception s'est produite, garantissant que le programme libère toujours la ressource même en cas d'erreur. Cela donne à votre code une documentation explicite sur le moment où une ressource est acquise et quand elle est libérée, et cela garantit qu'une ressource peut être libérée dès que possible.
En revanche, vous ne pouvez pas réellement dépendre du runtime pour le fermer comme par magie immédiatement pour vous. Cela est dû au fait qu'il se ferme en invoquant le destructeur de l'objet, ce qui peut ou non se produire immédiatement. Python ne fait aucune garantie quant à l'invocation d'un destructeur, mais seulement que ce sera finalement lorsque l'objet sera récupéré. (Voir ici .) Actuellement, Python est implémenté de sorte qu'il se produit dès qu'il n'y a plus de référence à un objet. Mais il est facile de propager accidentellement des références à un objet, et l'exécution de Python peut changer.
Pensez également à l'entretien à long terme. Il n'y a pas de référence à long terme maintenant, mais que se passe-t-il en 6 mois lorsque vous devez modifier le code pour qu'il y ait une référence? Et si quelqu'un d'autre le fait? La personne qui effectue le changement peut ne pas penser à passer à un with
bloc car il n'y en a pas déjà un. Faites du nettoyage de vos ressources une habitude et vous aurez beaucoup moins de problèmes avec cela.
Voulez-vous vraiment lier votre code aux détails d'implémentation de la récupération de place? Voulez-vous avoir constamment à réfléchir à la possibilité de propager accidentellement une référence via une exception? Non, non. Imaginez si cela s'est produit lorsque le script a été invoqué dans ArcMap. L'utilisateur serait obligé de fermer l'ensemble du processus juste pour libérer le fichier. Alors ne vous mettez pas dans cette position. Libérez la ressource explicitement. L'enregistrement d'une ligne de code ne vaut pas les risques de problèmes qu'elle peut causer. Les gestionnaires de contexte sont le mécanisme standard pour acquérir et libérer des ressources en Python, et ils le font très bien.
L'essentiel est que ne pas le publier explicitement est une mauvaise idée.
Bien entendu, cela suppose que le code a une certaine possibilité d'affecter quelqu'un d'autre, comme le mettre dans un script que quelqu'un d'autre devra exécuter ou maintenir ou cela pourrait retarder la livraison de votre travail si vous devez fermer ArcMap complètement parce que vous ne peut pas enregistrer vos modifications. Si vous êtes le seul à être touché par un problème, alors par tous les moyens, allez à l'encontre des bonnes pratiques tout ce que vous voulez.
da
curseurs: sgillies.net/2011/02/01/get-with-it.html et help.arcgis.com/ fr / arcgisdesktop / 10.0 / help / index.html # //… . En particulier, regardez les commentaires de @JasonScheirer au bas du premier lien.