Is using setup functions for commands, events, and tasks a good pattern for structuring a Discord.py bot?

Question

I'm refactoring on a Discord bot using discord.py and I've structured my project as follows:

my_discord_bot/
├── main.py
└── bot/
 ├── __init__.py
 ├── bot.py
 ├── commands.py
 ├── events.py
 └── tasks.py

In bot.py, I create the bot instance:

from discord.ext import commands
from discord import Intents
def create_bot():
 intents = Intents.default()
 intents.members = True
 intents.message_content = True
 return commands.Bot(command_prefix='!', intents=intents)
bot = create_bot()

To organize my code, I've separated commands, events, and tasks into their respective files. To initialize everything, I've created setup functions in each file:

In commands.py:

def setup_commands(bot):
 bot.add_command(command1)
 bot.add_command(command2)
 # ... more commands

In events.py:

def setup_events(bot):
 bot.event(on_ready)
 bot.event(on_message)
 # ... more events

In tasks.py:

def setup_tasks(bot):
 task1.start()
 task2.start()
 # ... more tasks

Then in main.py, I call these setup functions:

from bot.bot import bot
from bot.commands import setup_commands
from bot.events import setup_events
from bot.tasks import setup_tasks
def main():
 setup_commands(bot)
 setup_events(bot)
 setup_tasks(bot)
 bot.run(TOKEN)
if __name__ == "__main__":
 main()

My questions are:

1. Is this a good pattern for organizing a Discord bot?
2. Are there any potential issues or drawbacks to this approach?
3. Are there better alternatives for structuring a Discord bot project?

I'm particularly interested in hearing about best practices for larger Discord bot projects and how to maintain good separation of concerns.

• J_H: Looks good to me. I'm sad I didn't see any tests/task_test.py and similar, to exercise that target code.

Answer 1

1. That is definitely a really clean way to organize a Discord bot's code. You've split the different types of sections of code and you have setups for everything.
   
   
2. However, there can be drawbacks:
   • If you're anything like me, un-clean code can cause a lot of problems as you're splitting everything into multiple files and can easily lose track of a bug or something you're working on.
   • Because you've split them into different files, if you plan to utilize some values or functions from another file it could be a bit painful. Of course you could always create another file to store values you might use across files (like a file of constants, things that you might want to change across multiple files without changing every one of them manually, etc). Additionally sometimes you might run into circular import problems (a file imports a second file that tries to import the first file).
   • With a lot of different code spanning multiple files, you need to be extremely careful with your handling of code and error handling to make things work. Difficult to grasp things like command trees, sub commands, and hybrid commands could cause errors if not handled correctly.
     
     
3. Structurally, this is a really neat way to organize your project and might be one of the best ways. Something you could do if you don't have much code in main.py though is that you could move bot.py code there. This way you don't have as much "file clutter", especially when you have to deal with storing user data.

• Sᴀᴍ Onᴇᴌᴀ: Welcome to code review! Did you compose this solely on your own?
• keventhen4: @SᴀᴍOnᴇᴌᴀ Hello! Yes I did, I've had some experience with Python Discord bots. In fact just recently I revisited one of my old projects and attempted to incorporate slash/hybrid commands. By going through it I cut down 200 lines and fixed some previous issues. More experience and clean code is worth more than I would've expected before :)
• Sᴀᴍ Onᴇᴌᴀ: Nice! Thank you for contributing and responding.
• Hofbr: Yes that is a good point about file clutter. I was beginning to have the problem in my first iteration that functions were kind of cluttered and all over the place. Though I have run into the problem many times where functions eventually stop fitting nicely into one logical "file". Probably is best to be a bit more general in how I organize the code. I did abandon this structure. I may post an update to get some feedback on.