You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proposal will solve this issue on a small level, but when the payload size is big and there are multiple consumers who are consuming the dispatched event at the same time this will become a big issue it will block all the memory. Especially for long-running tasks or coroutines.
A quick fix that comes into my mind is writing a wrapper inside dispatch to make the payload a frozen dict.
multiple handlers could accept it, frozen dict won't change. if anyone wants to change any property of that dict they could create a separate copy of that dict or get items from that dict.
@danielhasan1 you're right. I haven't tried to address this issue because the payload can technically be of any type, not just dict. Either approach risks breaking the user's code if the payload contains values (custom objects, etc) that cannot be cloned or frozen.
I'm also not aware of any "standard" approach to making a dict immutable as PEP 416 was rejected and PEP 603 is still under drafting stage.
I think it's not about this library, it's about our design. events should be immutable. as a developer you should try design to have immutable events. for example you can try pydantic frozen classes or frozen dataclass or something that guarantee immutable events.
one suggestion is to change library to only accept immutable events data :D
Today, an event with multiple local handlers registered can interfere with each other as all handlers are given the same shared copy of events.
For instance,
Proposal
A copy of the payload should be passed to the handlers.
The text was updated successfully, but these errors were encountered: