Skip to content
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Build Status

A Qt style signal implementation that doesn't require QObjects. This supports class methods, functions, lambdas and partials.

Signals can either be created on the instance or on the class, and can be handled either as objects or by string name. Unlike PyQt signals, PySignals do not enforce types by default as I believe this is more pythonic.

Available under the MIT license.

Check out my website too for more programming and film related content:


You can install this using pip

pip install PySignal

This is compatible with Python 2.7+ and 3.x


def greet(name):
    print "Hello,", name

class Foo(object):
    started = ClassSignal()
    classSignalFactory = ClassSignalFactory()

    def __init__(self):
        super(Foo, self).__init__()

        self.signalFactory = SignalFactory()
        ended = Signal()

foo = Foo()
# Hello, Watson
# Hello, Sherlock
# Hello, Moriarty
# Hello, Mycroft

Signal Types

There are 4 types of Signals included

  • Signal is the base implementation of the Signal and can be created on a per instance level.
  • ClassSignal is an object that can be created as a class variable and will act like a signal. This ensures that all instances of your class will have the signal, but can be managed individually.
  • SignalFactory allows you to have a single signal object on your instance that can generate signals by name.
  • ClassSignalFactory is the same as a signal factory but lives on the class instead of the instance.

Why Signals?

Signals allow for creating a callback interface on your object and allows for it to be extended without needing to make a new inherited class.

For example I can define the following

class Foo(object):
    started = ClassSignal()
    ended = ClassSignal()
    def run(self):
        # Do my logic here

This does a few things:

  • It guarantees that any instances of Foo or it's subclasses will always have the started and ended Signals. This allows for a guaranteed interface.
  • It means that when we want to add callbacks to Foo, we can do so on a case by case basis without having to subclass it to call the slots explicitly.

For example:

foo1 = Foo()
foo2 = Foo()

foo1.started.connect(lambda: print("I am foo1"))
foo2.started.connect(lambda: print(42)) # will output I am foo1 # will output 42

We can also get the Signal's "sender" - the bound method responsible for emitting the signal, if available.

For example:

bar_run1 = foo1.started.sender() # will output <bound method of <__main__.Foo object at ...>>
bar_run2 = foo2.started.sender() # will output <bound method of <__main__.Foo object at ...>>

print(bar_run1 == # will output True
print(bar_run1 == # will output False
print(bar_run1 == bar_run2) # will output False

Instead of having to subclass Foo and implement the new behavior, we can simply reuse the existing Foo class and attach on to its instances.

What's missing?

The goal of this library is to mimic Qt's callback system without requiring all either end of the signal/slot to be a QObject derivative.

That said in the current state it is missing the following features:

  • It does not handle multiple threads. The slots are called in the same thread as the signal. This is because I am currently not aware of a way to do this in Python without implementing an equivalent to QObject which I am trying to avoid.
  • There is no type checking. Qt requires signals to declare the type of the data they emit. This is great for C++ but I feel it's not very pythonic and so do not implement that behavior.
  • You cannot query the sender. In Qt you can check what object sent a signal. Again this relies on inheriting from a QObject and Qt managing states, which are somethings I was trying to avoid. The alternative is that you can send self as the first parameter of the signal. e.g. signal.emit(self, arg1, arg2) and the slot will need to expect the first argument to be the sender.

If anyone has any suggestions or solutions on how I can overcome these caveats, I'm all ears and very willing to implement it or accept pull requests from other people too

Comparisons To Other Libraries

There are a few other libraries to compare with that implement Signals. I am not completely familiar with them so please correct me if I am wrong. These may serve your purposes better depending on what you are doing. The goal of PySignal is first and foremost to be a Qt style signal slot system so the comparisons are written with that in mind.


Blinker appears to implement a very similar signal to slot mechanism. It is inspired by the django signal system.

  • It has a few more convenience methods like temporary connections and the ability to handle dispatch logic based on input
  • It does not try and keep the Qt interface naming since it prefers the django system instead
  • It does not appear to support partials and lambdas


SmokeSignal is another django inspired signal system.

  • It has a decorator based interface with a focus on slots rather than signals. ie slots listen for a signal rather than a signal calling a list of slots.
  • It has support for one time calls
  • It supports contexts that can fire signals on entry and exit.
  • It does not implement a Qt style signal slot interface
  • It does not appear to support partials and lambdas.



  • Basic support for retrieving a Signal's "sender", with some test coverage.


  • no longer imports the PySignal module and instead parses it.
  • Test Coverage has been expanded to 97%
  • Slots can no longer be attached multiple times which used to cause them firing multiple times.
  • Using callable to find if slot is lambda


  • Initial Release

Based on these implementations


Many thanks to:

  • Alex Widener for cleaning up my
  • Adric Worley for expanding test coverage, cleaning up the code and fixing a duplicate connection bug.


A purely Python implementation of the Qt signal system with no QObject dependencies




No packages published


You can’t perform that action at this time.