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
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.
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.
changing recipient to recipients is a breaking change, as there is no restriction on the argument to be a non-keyword one,
having to resort to type-sniffing is doomed to fail, for example if someone provide a tuple instead of a list, or alike
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"
explicit is better than implicit
So in conclusion […], I suggest […] to add new methods, instead of changing existing ones.
The text was updated successfully, but these errors were encountered:
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:
TARGMAX
allowsIn 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 asrecipient
is the one that really requires forethought. I just don't want to complicate thebot
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 insay()
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, likemulti_say
.recipient
torecipients
is a breaking change, as there is no restriction on the argument to be a non-keyword one,say
orreply
is to reply to the sender of a trigger, and it is very unlikely that anyone want an implicit "send to multiple recipients"So in conclusion […], I suggest […] to add new methods, instead of changing existing ones.
The text was updated successfully, but these errors were encountered: