Interesting article. I liked the part where you point out that various concepts in PyQt/PySide really just stem from the needs in the C++ world, but don't always carry the same relevance in python (QString, QVariant, ...). C++ had to do a lot more work to add the "dynamic" characteristics it provides (introspection and whatnot).
Although, I did feel it was a bit light around the subject of what the pyqtSignal() is, and what you can't assign a fresh instance in your constructor. I haven't read the qt source code much, so I am not speaking from any sort of concrete wisdom. But I assume it's similar to the common python metaclasses. Methods start out as unbound methods, and transform into bound methods for each instance, encapsulating the reference to the instance. But with the signals, there is an added layer of needing to register with meta aspects of the Qt framework. This would be the reason you cannot replace an instance of the signal with a python object in the constructor. The underlying C++ layer has no knowledge of it. The same as how you can't replace *every* method on an existing QObject (or subclass) and expect it to be called. You can only do that with methods marked virtual. I was curious about this bit: "You’ll notice that if you try and send a signal from another thread, the recieving thread *might* crash on you. And therein lies the beauty of multi-threaded operations, or operations that share resources and try and access them simultaneously. This includes any use of QThread and the Python threading module." Can you expand on where this information comes from? What kind of crashes have you experienced, that you attribute them to the use of Signals and QThreads/Threads? On Mon, Jan 20, 2014 at 9:18 PM, Marcus Ottosson <[email protected]>wrote: > Couple of months later, I've had a go with multiple inheritance and with > injecting signals via a builder method. > > The builder works rather well and serves the majority of needs, as > "subclasses" would instead be monkey-patched and dependency injected to > conform to the given interface (i.e. a fixed set of basic signals and > functionality). > > Signals not being inherited or transferable was solved by making my own > signal class. > > If anyone is interested, I expanded on some of the pros and cons of that > here: > http://www.abstractfactory.io/blog/dynamic-signals-in-pyqt/ > > > On 27 October 2013 14:34, Marcus Ottosson <[email protected]> wrote: > >> Thanks Justin, I'll give that a go. >> >> I also found some interesting resources on the topic, as well as the >> issue of dynamically allocated signals. >> http://trevorius.com/scrapbook/python/pyqt-multiple-inheritance/#respond >> http://trevorius.com/scrapbook/python/binding-singals-dynamically/#respond >> >> >> On 26 October 2013 21:00, Justin Israel <[email protected]> wrote: >> >>> I think the multiple inheritance route is just fine, to consider your >>> abstract class as a mixin. The signal support is not a problem, since it >>> will be processed as part of the QObject's metaclass. >>> It's not legal to inherit from multiple QObjects, and you would see this >>> when you try and call the constructor on both, which means it doesn't even >>> really make sense to use a QObject as the base type of your mixin. >>> >>> class Abstract(QtGui.QWidget): >>> pass >>> >>> class Imp(QtGui.QLineEdit, Abstract): >>> def __init__(self): >>> QtGui.QLineEdit.__init__(self) >>> # Abstract.__init__(self) # <-- not legal >>> # RuntimeError: You can't initialize an object twice! >>> >>> >>> Just use object or some other non-qt type. And the naming scheme of >>> AbstractMixin, to me, indicates that it is to be used as a mixin and >>> doesn't have a custom constructor. >>> >>> But, the addition of your own metaclass to the mixin will result in a >>> conflict like this: >>> >>> TypeError: Error when calling the metaclass bases >>> metaclass conflict: the metaclass of a derived class must be a >>> (non-strict) subclass of the metaclasses of all its bases >>> >>> >>> I've actually used this python recipe to support Qt mixins that have a >>> metaclass and it worked great: >>> >>> http://code.activestate.com/recipes/204197-solving-the-metaclass-conflict/ >>> >>> >>> >>> On Oct 27, 2013, at 2:25 AM, Marcus Ottosson wrote: >>> >>> This is more of a general programming question, but I figured it applies >>> to Qt programming in particular and I keep encountering it without finding >>> any nice enough solution. >>> >>> I usually write an abstract interface for a set of classes and put >>> dependencies on the interface rather than their implementations. >>> >>> When subclassing QWidget however, how can you make an interface for >>> subclasses of an already implemented class? Is multiple inheritance a good >>> idea in this scenario? >>> >>> Currently, I'm writing the interface as a subclass of QWidget, is this a >>> good way? >>> >>> Thanks, >>> Marcus >>> >>> >>> -- >>> *Marcus Ottosson* >>> [email protected] >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBL_NwPBZrMhf12FEROVPnBV_8%2B8fAqyZ2OKXqsTabujw%40mail.gmail.com >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/78B20000-CC99-4A5F-9059-A287D7B0419E%40gmail.com >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> *Marcus Ottosson* >> [email protected] >> > > > > -- > *Marcus Ottosson* > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBssq4RmHN7iVYwrRJHUtUDkhKisqo1n3guUpefL34NVQ%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA23kWOA94QusaoT2Hh8vaqBkG3rH%3DyZmYyK8%3DjK_2yjVg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
