"AsyncBlink is a small extention to Blinker and enables you to use coroutines as receivers for your signals."

Seems to be essentially a modification of send() like so:

        # the only difference is here. If it's a coroutine,
        # run it with asyncio.async()
        receivers = self.receivers_for(sender) or []
        return_list = []

        for receiver in receivers:
            ret = receiver(sender, **kwargs)
            if asyncio.coroutines.iscoroutine(ret):
                ret = asyncio.async(ret)
            return_list.append((receiver, ret))

        return return_list

Useful to have this in Blinker natively? Perhaps something ala:

def send_async(self, *sender, **kw):
    wrapped = lambda v: asyncio.coroutine(lambda: v)
    values = [(r, wrapped(v)) if asyncio.iscoroutine(v) else (r, v)
                   for r, v in self.send(*sender, **kw)]
    return asyncio.gather(*values)

cc: @jucacrispim

@jek iirc you can click somewhere in the settings to move a repo to a new github org.

guess that is the easiest option to get it there.

i'ld offer to do some basic maintenance if i get the permissions (like for flatland, including a new pypi release with the new URL).

Use Cython if exists to speed up the checking if there are receivers. if Cython cant be found it uses a none optimized version.

A couple of considerations:

1. Cython module can be marked as required, speeding up all environments. But this is up to you.
2. The TypeError error raised when more than one sender is given as a param is done AFTER checking the availability of the receivers. it might broken a bit the contract.

Fixes https://github.com/jek/blinker/issues/46.

EOL Python versions are no longer supported by the core Python team and no longer receive security updates.

https://en.wikipedia.org/wiki/CPython#Version_history

They're also little used. Here's the pip installs for Blinker from PyPI for last month:

| python_version | percent | download_count | | -------------- | ------: | -------------: | | 2.7 | 50.71% | 88,260 | | 3.6 | 28.01% | 48,749 | | 3.5 | 14.50% | 25,235 | | 3.4 | 6.41% | 11,153 | | 3.3 | 0.17% | 290 | | 3.7 | 0.13% | 234 | | 2.6 | 0.08% | 131 | | 3.2 | 0.00% | 2 |

Source: pypinfo --start-date -49 --end-date -22 --percent --pip --markdown Blinker pyversion

Dropping them eases the maintenance burden and allows more modern features of Python to be used, some of which is included here.

For example,

https://github.com/jek/blinker/blob/b5e9f0629200d2b2f62e13e595b802948bb4fefb/blinker/base.py#L250

Causes the following deprecation warning.

DeprecationWarning: invalid escape sequence \*

Here's a reproduction.

import warnings
warnings.simplefilter("always")
x = "\*\*kwargs"
# <stdin>:1: DeprecationWarning: invalid escape sequence \*

Instead, the \* should be replaced by \\*. The following does not raise a DeprecationWarning.

import warnings
warnings.simplefilter("always")
x = "\\*\\*kwargs"

Not a huge deal, but these warnings pollute my build logs.

Hello,

It will be nice to add Continuous Integration. Please go to https://travis-ci.org/ and enable your blinker project

add a .travis.yml file with

language: python
python:
  - "2.7"
  - "3.2"
  - "3.3"
  - "3.4"

# command to install dependencies
install:
  - "pip install ."

# command to run tests
script: nosetests

then you can push your code.

Kind regards

When running pytest on test suite of my work project I have the following warnings at the end of test run:

.venv/lib/python3.8/site-packages/blinker/base.py:93: 11 warnings
  /usr/lib/publishing/.venv/lib/python3.8/site-packages/blinker/base.py:93: DeprecationWarning: invalid escape sequence \*
    """Connect *receiver* to signal events sent by *sender*.

.venv/lib/python3.8/site-packages/blinker/base.py:161: 11 warnings
  /usr/lib/publishing/.venv/lib/python3.8/site-packages/blinker/base.py:161: DeprecationWarning: invalid escape sequence \*
    """Connect the decorated function as a receiver for *sender*.

.venv/lib/python3.8/site-packages/blinker/base.py:242: 11 warnings
  /usr/lib/publishing/.venv/lib/python3.8/site-packages/blinker/base.py:242: DeprecationWarning: invalid escape sequence \*
    """Emit this signal on behalf of *sender*, passing on \*\*kwargs.

I guess those docstrings should be r"""...""" strings to avoid such warnings. Or \* sequences should be simply replaced by *.

Deps:

• CPython 3.8.6
• pytest 6.1.0
• blinker 1.4

  py25: commands succeeded  # no python2.5 on my system
  py26: commands succeeded  # no python2.6 on my system
  py27: commands succeeded  # ok
  py30: commands succeeded  # no python3.0 on my system
  py31: commands succeeded  # no python3.1 on my system
  py32: commands succeeded  # no python3.2 on my system
  py33: commands succeeded  # no python3.3 on my system
ERROR:  py34: InterpreterNotFound: python3.4  # ok
ERROR:  py35: InterpreterNotFound: python3.5  # ok
  py36: commands succeeded  # ok
ERROR:  jython: InterpreterNotFound: jython  # ok

So it says "succeeded" although there was no such python interpreter...

Just thought I'd let u know (from having made this same mistake myself),

But the application of @_utilities.lazy_property isn't actually thread-safe.

An example program you can try:

import threading
import thread

import time

from blinker import _utilities


class SlowThing(object):

    @_utilities.lazy_property
    def b(self):
        print "starting reading 'b' thread %s" % thread.get_ident()
        time.sleep(0.5)
        print "finished reading 'b' thread %s" % thread.get_ident()
        return 1

s = SlowThing()


def _run():
    s.b


threads = []
for i in range(0, 5):
    t = threading.Thread(target=_run)
    threads.append(t)
    t.start()


while threads:
    t = threads.pop()
    t.join()

The output of this will create:

starting reading 'b' thread 140684440516352
starting reading 'b' thread 140684432123648
starting reading 'b' thread 140684423730944
starting reading 'b' thread 140684415338240
starting reading 'b' thread 140684203915008
finished reading 'b' thread 140684432123648
finished reading 'b' thread 140684440516352
finished reading 'b' thread 140684423730944
finished reading 'b' thread 140684415338240
finished reading 'b' thread 140684203915008

So u can see there are many threads at the same time recomputing that property (in this case it doesn't matter, but in other cases it might?)

Some code that I have made that does appear to work fine:

Perhaps we can share it somehow...

https://github.com/openstack/taskflow/blob/master/taskflow/utils/misc.py#L346

I found a big memory leaks in my project. After studying the problem I have identified the source of the leaks is a dictionaries Signal._by_sender and Signal._by_receiver. I fixed this problem and create the pull request. Please, accept it and release new version of "blinker".

from setup.py / tox.ini:

[tox]
envlist = py25,py26,py27,py30,py31,py32,py33,py34,py35,jython

          'Programming Language :: Python :: 2',
          'Programming Language :: Python :: 2.4',
          'Programming Language :: Python :: 2.5',
          'Programming Language :: Python :: 2.6',
          'Programming Language :: Python :: 2.7',
          'Programming Language :: Python :: 3',
          'Programming Language :: Python :: 3.0',
          'Programming Language :: Python :: 3.1',
          'Programming Language :: Python :: 3.2',
          'Programming Language :: Python :: 3.3',
          'Programming Language :: Python :: 3.4',
          'Programming Language :: Python :: 3.5',
          'Programming Language :: Python :: 3.6',

Python 2.6 didn't get new releases since 5 years, so I guess for a new blinker release everything older than 2.7 could be dropped.

The last 3.2 release is also 4y old, so guess all < 3.3 could be dropped (if not even more).

People still using ancient versions can still use the older blinker release(s).

Also, tox and setup.py pypi metadata should be kept in sync.

Bumps certifi from 2022.6.15 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This allows for signals to send to coroutine receivers by awaiting them. The _async_wrapper and _sync_wrapper allows for conversion of sync and async receivers as required if defined. If not defined a runtime error is raised.

The wrappers are used to avoid any direct tie into asyncio, trio, greenbacks, asgiref, or other specific async implementation.

I have an application that generates reports from a bunch of sources. When a report is generated, a Blinker signal report_created is called, and one of the receivers sends an email to subscribers of that report type.

It sometimes happens, however, that we want to (re/)generate a large amount of reports. In such cases we don’t want email sending to happen. However, if an actual report gets generated meanwhile by the normal means, i want the receiver to be called, so i can’t just disconnect that receiver.

What i could imagine is something like this:

with report_created.disable():
    generate_a_lot_of_reports()

As far as i understand, this is not possible in the current Blinker version, but please correct me if i’m wrong. Also, if this use case seems valid (ie. not a unicorn case, when only my project needs it) i’m willing to dig deeper and submit a PR for this.

Having type hints for this library would make it possible to check its usage in applications with Mypy. I currently have a work-in-progress of those type hints.

Before it can be accepted into python/typeshed, I need to get the permission from the maintainers, so is it OK if I submit Blinker stubs to typeshed?