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

irc, bot, builtins: add & use AbstractBot.make_identifier_memory() helper #2552

Merged
merged 7 commits into from
Nov 17, 2023

Conversation

dgw
Copy link
Member

@dgw dgw commented Nov 9, 2023

Description

Here is a shortcut way of getting a new SopelIdentifierMemory with the identifier_factory kwarg filled in for you so it automatically uses the bot's awareness of casemapping from the IRC server's ISUPPORT tokens.

Manual casemapping selection is still possible by using the SopelIdentifierMemory constructor directly, of course, as before.

Using this new method in the bot to initialize its users and channels automatically adds this to test coverage:

image

(NB: That is an older coverage run, from before I expanded the docstring.)

Checklist

  • I have read CONTRIBUTING.md
  • I can and do license this contribution under the EFLv2
  • No issues are reported by make qa (runs make lint and make test)
  • I have tested the functionality of the things this change touches

@dgw dgw added the Feature label Nov 9, 2023
@dgw dgw added this to the 8.0.0 milestone Nov 9, 2023
@dgw dgw requested a review from a team November 9, 2023 21:08
This is a convenience method for people who just want default behavior
matching what Sopel itself does internally. The common use cases for
`SopelIdentifierMemory` require that its casemapping behave the same as
what Sopel's using, and this simplifies getting there.
@dgw dgw force-pushed the bot-identifiermemory-helper branch from d953f68 to 46977b6 Compare November 9, 2023 21:18
@dgw
Copy link
Member Author

dgw commented Nov 9, 2023

That'll teach me to skip at least make lint because "it's only a docs patch". 😅

Copy link
Contributor

@SnoopJ SnoopJ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice little ergonomics improvement for the core, builtins, and plugin developers.

Copy link
Contributor

@Exirel Exirel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise, I'm OK. I think however that this would be better with at least one automated test, probably in test/test_coretasks.py, by following the same ideas as the test_handle_issuport_casemapping test.

@dgw
Copy link
Member Author

dgw commented Nov 11, 2023

this would be better with at least one automated test, probably in test/test_coretasks.py, by following the same ideas as the test_handle_issuport_casemapping test.

I'm unclear on what you want to test for that isn't already covered by use of the new method in other already-tested locations.

If it's about the memory's existing keys updating with the new casemapping behavior when CASEMAPPING comes in from the server, only the bot's own _nick is rebuilt in that case. Previously-constructed Identifiers anywhere else in the program retain their old casemapping (and their old chantypes), and this isn't unique to the SopelIdentifierMemory type. There's no reasonable way to bot.rebuild_nick() for all existing Identifier objects out there.

About the best I can do—without rewriting a bunch of stuff and taking this PR far away from the original scope—is to check adding "the same" nick that now is "not the same" under the new casemapping rules. Even that's problematic, though: if Test[a] is added to the memory before CASEMAPPING comes in (using the default rfc1459 behavior), and then CASEMAPPING=ascii comes in, you still won't be able to add test{a} to the memory because the old rfc1459 casemapping already matches that:

memory = bot.make_identifier_memory()
memory['Test[a]'] = False

# the bot gets `CASEMAPPING=ascii` in here (omitted for brevity)
# but the previous casemapping is still in effect for the previously-added key:
assert memory['Test{a}'] == False

memory['tEST{a}'] = True  # this overwrites the previous value; it doesn't add a new key
assert len(memory) == 2  # this fails; len(memory) is (still) 1

Plugins probably just shouldn't construct Identifer before the bot has connected (e.g. in setup()). Do we need a guard on these methods that raises an error if the bot isn't ready yet? I've just thought that we could (in the future) give make_identifier() a manager that keeps track of all Identifiers it's created and then all of them could be updated if the CASEMAPPING changes. But that kinda sounds like overkill…

@dgw
Copy link
Member Author

dgw commented Nov 11, 2023

I pushed new stuff based on IRC discussion, not just out of the blue. I promise!

@Exirel
Copy link
Contributor

Exirel commented Nov 11, 2023

I'm unclear on what you want to test for that isn't already covered by use of the new method in other already-tested locations.

As discussed on IRC, the TL;DR is: this method need to be covered by direct invocation in the test suite, so if we stop using it internally, it is still tested and properly covered.

For everything else, the new commit with the added tests is the way to go.

@dgw
Copy link
Member Author

dgw commented Nov 11, 2023

As discussed on IRC, the TL;DR is: this method need to be covered by direct invocation in the test suite, so if we stop using it internally, it is still tested and properly covered.

I added the specific tests of bot.make_identifier() and bot.make_identifier_memory() in test/test_irc.py while I was here, to give both related methods a direct invocation from the test suite that isn't incidental to other test cases like test/test_coretasks.py's previously-existing test_handle_isupport_casemapping unit, in addition to the newly added test_handle_isupport_casemapping_identifiermemory test.

If you have another idea before merge (or after, idc), just holler @Exirel :)

@Exirel
Copy link
Contributor

Exirel commented Nov 11, 2023

I already approved that years ago. 😎

@dgw
Copy link
Member Author

dgw commented Nov 11, 2023

We had ourselves a spirited discussion about the idea of having make_identifier_memory() take an argument like the SopelIdentifierMemory() constructor now can (after #2525), with a lot of shifting opinions as more considerations came up.

I think the three of us (@Exirel, @SnoopJ, and myself) landed on the idea that it's fine to ship this as-is and come back to add an optional argument in 8.1.0. At the same time, we can clean up the messy *args argspecs throughout tools.memories.

Assuming we don't change our consensus in the next few days, this will get merged and this comment should be the basis of a new issue for 8.1 regarding signatures both here and in the Memory types.

@dgw dgw merged commit 9103422 into master Nov 17, 2023
15 checks passed
@dgw dgw deleted the bot-identifiermemory-helper branch November 17, 2023 21:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants