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

Deprecate this project? #671

Open
Dreamsorcerer opened this issue Feb 4, 2025 · 0 comments
Open

Deprecate this project? #671

Dreamsorcerer opened this issue Feb 4, 2025 · 0 comments

Comments

@Dreamsorcerer
Copy link
Member

Dreamsorcerer commented Feb 4, 2025

This library seems overkill when it basically provides only 2 or 3 lines of functional code. This creates overhead for downstream packagers etc. to package aiohttp (e.g. new packagers, or I've seen discussions of whether a security team wants to take ownership of aiohttp package but were discouraged by the number of dependencies they'd also need to support).

I'd suggest we move the code back into aiohttp and archive this project, or alternatively just add the class to frozenlist for other projects to use.

I'm not convinced the owner parameter is even useful in this project, so the entire project could just be (after tweaking frozenlist to use the class name in the repr):

class Signal(FrozenList):
    __slots__ = ()

    async def send(self, *args, **kwargs):
        if not self.frozen:
            raise RuntimeError("Cannot send non-frozen signal.")

        for receiver in self:
            await receiver(*args, **kwargs)

@mjpieters Any thoughts? If we proceed, I'll do a search of projects that might be using the library and provide them with PRs to migrate, as it's probably only a few.

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

No branches or pull requests

1 participant