Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix _ProactorEventLoop initialization bug #53

Closed
wants to merge 1 commit into from

Conversation

peterazmanov
Copy link
Contributor

QtCore.QObject.__init__(self) and asyncio.ProactorEventLoop.__init__(self, _IocpProactor()) causes double initialization of asyncio.ProactorEventLoop, according to mro.
Possibly related to #38.

`QtCore.QObject.__init__(self)` and `asyncio.ProactorEventLoop.__init__(self, _IocpProactor())` causes double initialization of asyncio.ProactorEventLoop, according to mro.
Possibly related to harvimt#38.
@aknuds1
Copy link
Collaborator

aknuds1 commented Nov 16, 2015

@harvimt Do you have a Windows machine to test this on? I don't understand without testing why asyncio.ProactorEventLoop would get double initialized though.

@aknuds1
Copy link
Collaborator

aknuds1 commented Nov 16, 2015

Is it because QObject calls super().__init__() that asyncio.ProactorEventLoop gets double initialized? Difficult to tell without testing.

@aknuds1
Copy link
Collaborator

aknuds1 commented Nov 16, 2015

I tested on OS X, AFAICT QObject does indeed call super().__init__() so that the next baseclass (ProactorEventLoop) gets initialized twice. So, in summing up, looks good to me.

@peterazmanov
Copy link
Contributor Author

@aknuds1 I tested this on Windows 7 machine with Python 3.4

@rutsky rutsky mentioned this pull request Nov 16, 2015
@harvimt
Copy link
Owner

harvimt commented Nov 18, 2015

I'm worried that this will be different depending on which Qt implementation is used.
I suggest moving the object that can receive the signal into it's own object instead of subclassing QObject and ProactorEventLoop like I do in #29.

@peterazmanov
Copy link
Contributor Author

@harvimt why _ProactorEventLoop (or any class in the quamash.QEventLoop hierarchy) needs inheritance from QObject? AFAICT, unix implementation is different in this regard.

@harvimt
Copy link
Owner

harvimt commented Nov 18, 2015

to receive Qt signals, but like I said a better implementation is a
dedicated signal receiver object.

On Wed, Nov 18, 2015 at 3:39 AM, Peter Azmanov notifications@github.com
wrote:

@harvimt https://github.com/harvimt why _ProactorEventLoop (or any
class in the quamash.QEventLoop hierarchy) needs inheritance from QObject?
AFAICT, unix implementation is different in this regard.


Reply to this email directly or view it on GitHub
#53 (comment).

@peterazmanov
Copy link
Contributor Author

@harvimt PyQt successfully connects signals to methods of non-QObject-subclass class. PyQt docs

@harvimt
Copy link
Owner

harvimt commented Nov 18, 2015

Sorry not receive or send, but declare.
Only EventPoller needs to be a QObject, I fix this in 847df31, (which is part of #29, which I never merged)

@harvimt harvimt closed this Nov 18, 2015
@harvimt
Copy link
Owner

harvimt commented Nov 18, 2015

I cherry-picked 847df31, and updated the docstrings so flake8-docstrings stops bugging (new check they added), so this is fixed in master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants