在调用deleteLater()后直接删除一个Qt对象的Python引用是否安全?

问题描述 投票:1回答:1

请考虑下面这个最小的例子,它实现了一个自定义的 QNetworkAccessManager 列表,维护一个未完成的 QNetworkReply 实例。

当答复是 finished,它被从 unfinished_replies 列表。

中所讨论的。在PyQtPySide中需要deleteLater()吗?, QNetworkReply.deleteLater() 使用的,里面的 finished 槽,来安排Qt对象的删除。

然而,我不确定删除回复对象的Python引用的最佳方式是什么。我可以想到两种 (相互排斥的) 删除 Python 引用的方法,如下例所示。

  1. 直接在调用 deleteLater()

  2. 撤下 QNetworkReply.destroyed 发出信号(文件)

两种方案似乎都很好用。我更倾向于选择1,但我不知道这是否会导致在极少数情况下出现意外。哪种方案最好?还是有其他的选择?

import sys
from PyQt5 import QtNetwork, QtWidgets, QtCore


class CustomNetworkAccessManager(QtNetwork.QNetworkAccessManager):
    def __init__(self):
        super(CustomNetworkAccessManager, self).__init__()
        self.unfinished_replies = []
        self.finished.connect(self.slot)

    def get(self, *args, **kwargs):
        reply = super(CustomNetworkAccessManager, self).get(*args, **kwargs)
        reply.index = i  # just for printing
        self.unfinished_replies.append(reply)

    def remove_from_list(self, reply):
        self.unfinished_replies.remove(reply)
        print('{} unfinished replies left'.format(len(self.unfinished_replies)))
        if not self.unfinished_replies:
            QtCore.QCoreApplication.quit()

    def slot(self, reply):
        print('reply {} finished'.format(reply.index))
        # handle the Qt side:
        reply.deleteLater()  
        # handle the Python side:
        # either
        # OPTION 1 - remove now
        self.remove_from_list(reply)
        # or 
        # OPTION 2 - remove when destroyed
        # reply.destroyed.connect(lambda: self.remove_from_list(reply))


if __name__ == '__main__':
    # Initialize
    app = QtWidgets.QApplication(sys.argv)
    manager = CustomNetworkAccessManager()

    # Schedule requests
    url = 'http://httpbin.org/get'
    for i in range(6):
        manager.get(QtNetwork.QNetworkRequest(QtCore.QUrl(url)))

    # Start event loop
    app.exec_()

p.s.对不起,Python 2的代码。

python pyqt pyqt5
1个回答
2
投票

两者都是等价的,只是在删除的那一刻不同。但是要想更详细的理解,你必须了解PyQt5PySide2绑定的工作原理。这些库围绕C++对象创建了一个封装器,类似于。

class FooWrapper:
    def __new__(self, cls, *args, **kwargs):
         # ...
         instance = ...
         instance._cpp_object = create_cpp_object()
         # ...
         return instance

    def foo_method(self, *args, **kwargs):
        return execute_foo_method(self._cpp_object, *args, **kwargs)

    def __del__(self):
        destroyed_cpp_object(self._cpp_object)

所以当调用deleteLater时,只有cpp_object被删除,而不是包装器, 你可以通过使用:

reply.destroyed.connect(self.remove_from_list)
Traceback (most recent call last):
  File "main.py", line 32, in <lambda>
    reply.destroyed.connect(self.remove_from_list)
  File "main.py", line 17, in remove_from_list
    self.unfinished_replies.remove(reply)
ValueError: list.remove(x): x not in list

因为destroy传递的参数是一个无效的包装器,会出现上述错误。对于这种情况,一个解决方案是用sip.isdeleted()检查cpp_object是否已经被删除。

from PyQt5 import QtNetwork, QtWidgets, QtCore
import sip

# ...
class CustomNetworkAccessManager(QtNetwork.QNetworkAccessManager):
    # ...

    def remove_from_list(self):
        self.unfinished_replies = [
            reply for reply in self.unfinished_replies if not sip.isdeleted(reply)
        ]
        print("{} unfinished replies left".format(len(self.unfinished_replies)))
        if not self.unfinished_replies:
            QtCore.QCoreApplication.quit()

    def slot(self, reply):
        print("reply {} finished".format(reply.index))
        # handle the Qt side:
        reply.deleteLater()
        # handle the Python side:
        reply.destroyed.connect(self.remove_from_list)

回到对你的方法的研究, 这些方法可以绘制成如下图:

(FIRST METHOD)
------------┬------------------┬---------------------┬-----------------------
            |                  |                     |
 call_deleteLater remove_reply_from_list          destroyed
(SECOND METHOD)
------------┬-----------------------------------------┬-----------------┬------
            |                                         |                 |
 call_deleteLater                               destroyed remove_reply_from_list

由于你使用的是原始的封装器,你应该不会有任何问题。

结论。 两者都是等价和安全的。

© www.soinside.com 2019 - 2024. All rights reserved.