управление долгосрочными ресурсами в Python - PullRequest
0 голосов
/ 18 июня 2019

Я пишу средне-сложную программу на Python, использующую PyOpenGL.Для программирования OpenGL требуется много ресурсов, и мне интересно, как управлять их выпуском.

Исходя из того, что я понимаю, например, в C ++, общей стратегией было бы иметь классы, которые обертывают ресурсы, которые получаютресурс в их конструкторе и связать его в своем деструкторе, идиома RAII.RAII плохо работает в Python, потому что деструкторы (на самом деле, финализаторы) не вызываются детерминистически, как обсуждалось, например, здесь .

Как указывалось там, основным средством в Python для управленияРесурсы - это оператор with и контекстные менеджеры.Я не понимаю, как это масштабируется до средних и крупных программ, где код, использующий ресурс, не является единым набором утверждений.Оператор with может заменить механизм C ++ локальной переменной, содержащей ссылку на объект, выходящую из области видимости, но не механизм C ++ поля объекта, содержащего ссылку на объект, «истекающую», когда сам объект уничтожен.

Для простого примера , скажем, у меня есть класс, который при создании экземпляра открывает файл для записи, например, для ведения журнала.Этот файл остается открытым в течение всего (функционального) существования объекта и записывается различными способами.Из-за того, что написание распространяется по различным методам, оператор with не применимИтак, как мне убедиться, что файл закрыт, когда объект больше не используется?

Сделать ли сам класс менеджером контекста (реализовать __enter__ и __exit__) и дать клятву использовать только экземплярыс помощью with операторов?

Или я должен связать каждый метод __init__ с методом close и дать клятву всегда вызывать этот метод, когда объект больше не нужен?

Что такое Pythonic way?

Я прошу прощения, если этот вопрос не особенно ясен;это потому, что я пытаюсь сосредоточиться на чем-то, чего я не совсем понимаю.Я был бы признателен за любые комментарии о том, как сделать это более понятным.

Личная информация: я не программист на C ++ и вообще не много делал ООП, но то, что я понимаю в ООП, вероятно, формируетсячто я читаю о C ++.

...