[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] Slot connections fail with newest snapshot
From:       Phil Thompson <phil () riverbankcomputing ! com>
Date:       2016-07-21 15:55:49
Message-ID: C745DB78-384E-4AA4-BA28-54B07D33E756 () riverbankcomputing ! com
[Download RAW message or body]

On 21 Jul 2016, at 4:08 pm, Florian Bruhin <me@the-compiler.org> wrote:
> 
> * Phil Thompson <phil@riverbankcomputing.com> [2016-07-21 15:27:13 +0100]:
> > On 21 Jul 2016, at 3:05 pm, Florian Bruhin <me@the-compiler.org> wrote:
> > > 
> > > * Phil Thompson <phil@riverbankcomputing.com> [2016-07-21 15:03:21 +0100]:
> > > > On 21 Jul 2016, at 1:51 pm, Florian Bruhin <me@the-compiler.org> wrote:
> > > > > 
> > > > > * Phil Thompson <phil@riverbankcomputing.com> [2016-07-17 12:57:24 +0100]:
> > > > > > > > The current behaviour is different, but what are you expecting to
> > > > > > > > happen (given your class does not inherit from QObject)?
> > > > > > > 
> > > > > > > Oh, @pyqtSlot only works on classes inheriting from QObject? While
> > > > > > > that makes some sense, that's news for me!
> > > > > > > 
> > > > > > > I think either it should just be ignored (like before?), or show some
> > > > > > > useful error message like "pyqtSlot can only be used on classes
> > > > > > > inheriting from QObject" or so. I also think this should be pointed
> > > > > > > out in the docs for @pyqtSlot - while the examples do inherit from
> > > > > > > QObject, it's not explicitly documented anywhere I think.
> > > > > > 
> > > > > > You can use it in classes that are used as mixins with QObject derived \
> > > > > > classes.
> > > > > 
> > > > > Hmm, I see.
> > > > > 
> > > > > So for normal classes which are not QObject subclasses, @pyqtSlot was
> > > > > simply ignored so far?
> > > > 
> > > > Yes.
> > > > 
> > > > > What about using @pyqtSlot on free functions (rather than methods)?
> > > > > It seems that still works fine with the current snapshot - is that
> > > > > ignored as well?
> > > > 
> > > > Yes.
> > > 
> > > Will this stay that way, or will there be a warning/error added for
> > > that as well?
> > 
> > The only error is when you try and make an invalid connection. PyQt can't tell \
> > now a decorated function or method is going to be used so it shouldn't assume \
> > somebody hasn't found a valid use case.
> 
> I still don't quite follow, sorry - what's invalid about the
> connection in my original example[1] other than I'm using @pyqtSlot on
> a non-QObject?

The main purpose of pyqtSlot is to define a new entry in the QObject's QMetaObject, \
so you would normally only use it on a method. pyqtSlot doesn't check that the \
containing class is a QObject because it might be being used as a mixin. When the \
connection is made the receiver must be a QObject. In your case it isn't so the \
connection fails.

> And how is that different to connecting to a function with @pyqtSlot,
> i.e. why is that still "valid" while the above is invalid with
> PyQt 5.7?

I agree it is inconsistent. I could add an extra check to raise an exception if \
connecting to a slot which is a function (as opposed to a method) decorated with \
pyqtSlot, but (as the decorator is completely ignored) I don't really see the point.

Phil
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt


[prev in list] [next in list] [prev in thread] [next in thread]