Willie assumes channel names start with #

[ari-koivula]

In many places str.startswith("#") is used to check if the sender is a channel. This obviously fails for channels starting with "&", "+" and "!".

At least the following modules do this: bot, modules.adminchannel, modules.find and modules.meetbot.

Channels not starting with "#" are rare, but they do exist, so this should probably be fixed at some point.

[embolalia]

I checked dftba.net, Freenode, Gamesurge, EFNet, and Spotchat. Unless I'm missing something, only Gamesurge and EFNet support anything other than #, and even those only &. You're right, we should support this. We'll need to find a network that supports the other two kinds of channels if we're going to test it fully, though.

[ari-koivula]

All of these channel types work in IRCNet.

A decorator like @require_privmsg could be added to make adding this sort of guard simple for modules. Although, it should probably also be offered as a regular function. Other ideas for guard decorators would be @require_admin and @require_owner.

[lramati]

How would you implement it? Is that something you can do, given that you
need access to the trigger? (I'm not 100% on decorators, hence my asking)

[ari-koivula]

You wrap the function object, making sure not to hide any attributes or other important things. functools.wraps can do this.

[tyrope]

config option?
[core]chan_prefix=#,&

[elad661]

If we have a reliable way to detect whether it's private message or a channel message (and I don't think we do, because the protocol is vague like that), we should add something like trigger.is_private

[ari-koivula]

Adding a configuration option for this makes no sense, as this stuff is defined in rfc 2810 through 2813.

Checking the first character of sender is reliable. Channels always start with #, +, ! or & and nicknames never start with those.

[miggyb]

ZNC partyline support (private server channels) start with ~
http://wiki.znc.in/Partyline

psyBNC apparently uses either & or int~ for more complicated setups. At least one of the examples they give is /join int~#mychannel
http://www.psybnc.at/help.html

Not sure if IRC bot partyline support would be useful to anyone else, but I at least have one future project where it might be handy.

[lramati]

I just checked on Nerdfighteria Network, and we might be able to check that
it isn't a nick by checking for those characters, since they're all illegal
in a nick. I haven't been able to confirm this in the RFC from my phone,
but the RFC does mention a nick grammar that I was unable to find.

09:34] test# :Erroneous Nickname: Illegal characters
[09:35] test@ :Erroneous Nickname: Illegal characters
[09:35] test& :Erroneous Nickname: Illegal characters
[09:35] test~ :Erroneous Nickname: Illegal characters
[09:35] * You are now known as test^
[09:35] test* :Erroneous Nickname: Illegal characters
[09:35] test! :Erroneous Nickname: Illegal characters
[09:36] test+ :Erroneous Nickname: Illegal characters

[embolalia]

What we really need here is to support ISUPPORT's CHANTYPES. That would be the most robust way (with a default to the RFC's specified options). ISUPPORT also has CASEMAPPING for telling whether the case sensitivity weirdness regarding '[{' et al. is used. If we could somehow cause the Nick class to take these into account (and rename it to something appropriate), it could handle both nicks and channels, with some member to show whether it's a channel or not. Thus, ensuring something was only used in PM would be e.g. if trigger.sender.is_channel: return, while also making everything all nicely case-unsensitive.

[tyrope]

Hasn't this been fixed by now?

[EldonMcGuinness]

trigger.is_privmsg does exist which basically does this but in inverse.

# Check if this is from a channel
if not trigger.is_privmsg:
    do_something

The above would be the equivalent; part of PR #391
I guess someone could add an inverse right after it for trigger.is_channel.

One thing to note is it does not account for the situation miggyb mentioned above, it instead assumes the more common set of '#&+!' to be valid prefixes for channels as venti2 said.