search

shizmob / pydle

An IRCv3-compliant Python 3 IRC library.
BSD 3-Clause "New" or "Revised" License
154 stars 48 forks source link

QUIT/PART has inconsistent timing of destroy_user #131

Closed johnlage closed 4 years ago

johnlage commented 4 years ago

QUIT destroys the user after calling the on_quit callback, while PART destroys the user first. I'm kind of assuming QUIT's behavior is correct, and PART needs to be corrected, as having access to hostname/etc while running the callback is useful in some cases.

theunkn0wn1 commented 4 years ago

Hm, that does indeed sound problematic. At the very least the behavior should be consistent. Will investigate!

theunkn0wn1 commented 4 years ago

Looking at the relevant implementations, I don't see any specific reason why the callbacks would be invoked at different stages.

In the case of a quit, any and all users would become invalid since the bot is leaving. In the event of a pydle-client part all users that only existed in the effected channels would become invalid as they no longer exist as far as Pydle is concerned. Since the QUIT behavior allows users to be retrieved in the downstream on_quit callback prior to destroying them, and there are no Pydle-internal references to Client.on_part, I do not see any specific reason for these callbacks to occur at a later stage than quit.

In either event, there is value in being able to retrieve the user object for the parting user. I believe I will differ to the QUIT behavior for this specific issue.

johnlage commented 4 years ago

For reference, my testing was another user PART/QUITing the room the bot is in, not the bot PART/QUITing itself.

theunkn0wn1 commented 4 years ago

The on_part_raw event fires regardless to who it was parting, with deciding logic for discerning between the two modes.

Note the on_part and on_quit events will be called regardless of who it was that part/quit, which may be relevant to your implementation.

theunkn0wn1 commented 4 years ago

should be fixed in release 0.9.4