Description
Is your feature request related to a problem?
My Feature is related to the complexity of understanding TraceConfig Which could use some improvements especially when it comes to defining as well as creating callbacks. One of the ways I wanted to improve the code was by migrating to a less complex library that focuses on simplicity and speed by removing the bulk of the class object while retaining type hints for different parameters being used.
Describe the solution you'd like
By Migrating from aiosignal to aiocallback my hope is that aiohttp benefits from TraceConfig's source code being made smaller as well as being more optimized in the long run. Some Main key features to point out are
-
Aiocallback Reduces the code by a significant margin as no external classes are required for using it.
-
Aiocallback 1.5 which I plan to release soon has additional support for dataclass structures and you can get exteremely lazy with freezing events thanks to the EventList class Object.
EventLists in 1.5 have dataclass support for
attrs,standard python dataclasses&pydantic -
Aiocallback has support for using wrappers over using the append method.
-
Aiocallback supports all current versions of python that have not hit end of life.
-
Aiocallback uses member descriptors vs using standard custom lists and it can properly hint function parameters when static type checkers are in use.
Describe alternatives you've considered
One alternative I thought about if this request is denied is adding ParamSpec into Aiosignal or reworking traceconfig to use member descriptors to enhance it's pefromance.
Related component
Client
Additional context
I have a screenshot example from aiocallback's early days on my github for reference as to what I hope aiocallback will ultimately end up solving. With many annoyances gone my hope is for developers to try migrating to more modern and maintained tools such as my own which I hope to continue to maintain in years to come.
Code of Conduct
- I agree to follow the aio-libs Code of Conduct