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

Nicer API support for multiple recipients / TARGMAX #2343

Open
dgw opened this issue Aug 23, 2022 · 1 comment
Open

Nicer API support for multiple recipients / TARGMAX #2343

dgw opened this issue Aug 23, 2022 · 1 comment

Comments

@dgw
Copy link
Member

dgw commented Aug 23, 2022

Since Sopel is now aware of TARGMAX, we have the foundation of more efficient message sending available. Right now, plugins have to jump through some hoops in order to use it; see e.g. #1859.

I'm definitely in favor of the following conveniences:

  • Comma-separated recipients (supported now) automatically split and regrouped if the list is longer than TARGMAX allows
  • Option to pass a list, tuple, or set of str/Identifier, and group them automatically

In a perfect world this would "just work" as part of the existing say() & friends, but we need to think about that carefully. I have no concerns about automatically correcting comma-separated lists in string form—that's just to prevent plugin code from sending stuff with too many targets that the server would block anyway. Moving to support a list/tuple/set as recipient is the one that really requires forethought. I just don't want to complicate the bot methods available any more than necessary. One could argue there are already too many. (One could also argue that there are already too many optional parameters in say() et al.)

There will be discussion aplenty, I'm sure. This certainly won't be part of 8.0.

A relevant past comment I found is quoted below, to help start us off.


Originally posted by @Exirel in #1525 (comment)

The more I think about multi-recipients, the more I believe we should not handle these cases in methods like say and alike, but instead to add new methods, like multi_say.

  1. changing recipient to recipients is a breaking change, as there is no restriction on the argument to be a non-keyword one,
  2. having to resort to type-sniffing is doomed to fail, for example if someone provide a tuple instead of a list, or alike
  3. the most common use-case for say or reply is to reply to the sender of a trigger, and it is very unlikely that anyone want an implicit "send to multiple recipients"
  4. explicit is better than implicit

So in conclusion […], I suggest […] to add new methods, instead of changing existing ones.

@Exirel
Copy link
Contributor

Exirel commented Aug 23, 2022

That would be a nice "new feature in 8.1". 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants