TypeError when accessing `guild_only` property on commands/groups missing `contexts`

[MXUMX]

Summary

On a SlashCommandGroup with integration_types without contexts, reading its .guild_only property raises a TypeError

Reproduction Steps

1. Create a SlashCommandGroup (or SlashCommand) and provide the integration_types argument.
2. Explicitly omit the contexts argument (or leave it as None).
3. Attempt to access the .guild_only property on the instantiated command group or command.
4. Observe the resulting TypeError exception.

Minimal Reproducible Code

import discord

bot = discord.Bot()

# Define a group with integration_types but NO contexts
music_group = discord.SlashCommandGroup(
    name="music",
    description="Music commands",
    integration_types={discord.IntegrationType.guild_install}
)

# Attempting to read guild_only triggers the bug
print(music_group.guild_only)

Expected Results

The guild_only property should safely return a boolean value (e.g., False or evaluate based solely on integration_types) without crashing. Pycord's internal property logic should handle cases where self.contexts is None.

Actual Results

A TypeError is thrown immediately upon property access:

/Users/mx/Desktop//test.py:13: DeprecationWarning: guild_only is deprecated since version 2.6, consider using contexts instead.
  print(music_group.guild_only)
Traceback (most recent call last):
  File "/Users/mx/Desktop/test.py", line 13, in <module>
    print(music_group.guild_only)
          ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/mx/Desktop/.venv/lib/python3.14/site-packages/discord/commands/core.py", line 1352, in guild_only
    return InteractionContextType.guild in self.contexts and len(self.contexts) == 1
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument of type 'NoneType' is not a container or iterable

Intents

discord.Intents.default() (Note: Intents are irrelevant to this specific internal attribute/property bug, as it happens prior to bot connection.)

System Information

- OS: System agnostic (Windows / Linux / macOS)
- Python version: v3.10+
- Pycord version: v2.6.0+ (Including v2.8.0rc1)

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

Additional Context

This internal bug frequently breaks automated help cog generators or custom command tree iterators. When these scripts loop through bot.walk_application_commands() and evaluate command.guild_only to filter out non-guild commands for their dynamic UI, the loop crashes and skips commands entirely. A simple internal fix in Pycord's guild_only getter property would be to use a safety check, such as: if self.contexts is not None and InteractionContextType.guild in self.contexts.

I'm aware this method is deprecated, but I feel like this bug is still worth mentioning for people who still use guild_only.

The code that causes this problem should be:

pycord/discord/commands/core.py

Line 1348 in 71c48a2

return InteractionContextType.guild in self.contexts and len(self.contexts) == 1

[vmphase]

guild_only was deprecated in v2.6. Use the contexts parameter instead.

[vmphase]

Deprecated APIs are on a path to removal, so fixing bugs in them would be counterproductive, since it might encourage users to keep relying on the deprecated API instead of migrating. Furthermore, it feels pointless to investigate any effort into code that's going away anyway.

[Paillat-dev]

If this is an actual bug we should still try to fix it, as it might be breaking for someone upgrading. I'm going to take a look

[vmphase]

If this is an actual bug we should still try to fix it, as it might be breaking for someone upgrading. I'm going to take a look

The fix seems trivial: both ApplicationCommand/SlashCommandGroup.guild_only getters should guard self.contexts is not None.

[CodingEnte]

I presume my commit fixed the 'guild_only' issue.

It raised a type error when context was never set, since the getter ran 'in' on None. An unset contexts means no restriction, so it now returns
False instead of raising the error.