Signals refacoting #2480
Signals refacoting #2480
Conversation
@pfreixes the RP breaks your work on client tracing but I pretty sure the change is not big and is done for good. |
Should changes mention drop |
Sure. |
Codecov Report
@@ Coverage Diff @@
## master #2480 +/- ##
==========================================
+ Coverage 97.14% 97.15% +0.01%
==========================================
Files 39 39
Lines 8136 8097 -39
Branches 1420 1416 -4
==========================================
- Hits 7904 7867 -37
+ Misses 101 99 -2
Partials 131 131
Continue to review full report at Codecov.
|
class PostSignal(DebugSignal): | ||
|
||
__slots__ = () | ||
await receiver(*args, **kwargs) |
kxepal
Nov 8, 2017
Member
How about to add more friendly exception if plain func is going to be registered as handler? I guess now such code will fail with cryptic TypeError: object NoneType can't be used in 'await' expression
or similar.
How about to add more friendly exception if plain func is going to be registered as handler? I guess now such code will fail with cryptic TypeError: object NoneType can't be used in 'await' expression
or similar.
asvetlov
Nov 8, 2017
Author
Member
Do you suggest catching TypeError
and raise a new TypeError
with more informative exception message?
Do you suggest catching TypeError
and raise a new TypeError
with more informative exception message?
asvetlov
Nov 8, 2017
Author
Member
As an option we could check ll callbacks on freezing stage.
It prevents registering a regular function which returns a future but it's fine I guess.
As an option we could check ll callbacks on freezing stage.
It prevents registering a regular function which returns a future but it's fine I guess.
kxepal
Nov 8, 2017
Member
Yes for TypeError and yes, better check this early. On append call if possible. The stacktrace will help to find that bad signal usage with easy.
Yes for TypeError and yes, better check this early. On append call if possible. The stacktrace will help to find that bad signal usage with easy.
asvetlov
Nov 8, 2017
Author
Member
FrozenList can be modified by too many ways, .append
is not the only one.
I think .freeze()
is a good compromise.
FrozenList can be modified by too many ways, .append
is not the only one.
I think .freeze()
is a good compromise.
kxepal
Nov 8, 2017
Member
It's a pity. Ok then if error message would contains function name which is not async.
It's a pity. Ok then if error message would contains function name which is not async.
asvetlov
Nov 8, 2017
Author
Member
Well, but I see you point.
Maybe we need specialized CheckedFrozenList
class with registered callback? It could improve UX slightly.
Please let me merge the PR as is and make a new issue.
I don't want to block @pfreixes with his client tracing PR.
Well, but I see you point.
Maybe we need specialized CheckedFrozenList
class with registered callback? It could improve UX slightly.
Please let me merge the PR as is and make a new issue.
I don't want to block @pfreixes with his client tracing PR.
kxepal
Nov 8, 2017
Member
Ok. Let's do that.
Ok. Let's do that.
LGTM. Just take into account that Func signals might be needed later, but let's implement it once we know for sure that are gonna needed. |
@asvetlov what was intention to remove support of synchronous functions? We had to refactor all our backends due to this decision. Why not to write Also, about automatic detection: |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs. |
Fix for #2419