def is_solution(self):
    """Check if an equation is equal to self.max."""

    return (
        eval(self.equation) == self.game.game_max
    )

This checks if the equation is equivalent to the game max, but it should allow any number from 0 to the game max.

Title basically

Math interpreter should be in a separate module, which cleans the repository and should reduce redundant code.

Utilize Python data classes for some arguments of classes, when applicable

This reduces the large amount of redundancy in checking if values are of the valid type.

https://docs.python.org/3/library/dataclasses.html

Should help for MathGame and Equation classes specifically.

Allow a dictionary where an integer's value can alter the amount of that integer allowed.

Allow the parser to validate x(...) multiplication, instead of raising a syntax error. It should take higher precedence than normal multiplication and division.

Redesign the entire validation process. The current string processing method is (as said in the file) a temporary, buggy, and half-baked solution to validate user input.

Create another interpreter dedicated simply to validating user input (support for lists, dictionaries, single integers, strings?)

def is_solution(self):
    """Check if an equation is equal to self.max."""

    return (
        eval(self.equation) <= self.game.game_max
    )  # Temporary, will create a custom parser later

Allows for a number less than 0, if the equation meets other requirements.

ValueError should be replaced with another exception, such as a custom exception for incorrect class arguments of some sort, or possibly another exception for an invalid equation solution, which could be caught by the command (when developed) or the MathGame class.

ints and disallowed_operations arguments have no effect

Add modulo to the parser and interpreter

Might've forgotten about this one when programming the parser...

Move the interpreter sub-module to a separate repository, possibly publish on PyPI?

Lexer class should only accept Equation type equations, which allows the class to be further utilized.

It is also a good idea to remove redundant equation checking from the equation class itself, as the lexer should do that automatically.

This issue outlines how the verification feature (verifying possible types of user input) will convert into a type dictionary before being supplied to the MathGame class. This is a general plan for myself on implementing this checking functionality, most likely integrated into a separate class and file.

Important. All values passed as user input will be of type string. Depending on various criteria will determine if that string is considered valid regardless of the fact it can be represented as a numerical value.

All keys must be between 0-9. All values must be greater than 0.

Key values will be supplied to a method that outputs a boolean value, representing if the integer key is between 0 and 9. Values will do the same, instead of checking if the integer is greater than 0.

If a string value supplied to the get_numerical_form method is representable as type float, it will return exactly that, otherwise raising an exception.

If a supplied value is just of type int, it will be checked via the key criteria and converted into the following dictionary: {x: 1}.

If a user were to supply a list-like format (such as [1, 2, 3]), each item would be appended to the dictionary's keys and given a value of the number of its occurrences. Various types will be handled.

Dictionaries will be handled "as is", only raising an exception if the key or value does not follow the key and value criteria. Types will be handled,

I've already thought of possible issues during the development of this and will add to this as needed.

I plan to add further ways of expressing this in the future, and some functionality may not be necessary if discord provides a simple way to do this automatically.

@bot.tree.command(name="ping", description="Display the ping in milliseconds.")
async def ping(interaction: Interaction):
    """Display the ping in milliseconds."""

    latency = bot.latency * 1000
    await interaction.response.send_message(f"Pong! {latency:.2f}ms")

@bot.tree.command(
    name="server-count", description="Display the number of servers the bot is in."
)

This should return an Embed as it looks much cleaner on Discord GUI as opposed to plaintext.

@bot.tree.command(
    name="server-count", description="Display the number of servers the bot is in."
)
async def server_count(interaction: Interaction):
    """Display the number of servers the bot is in."""

    message = (
        f"I'm in {len(bot.guilds)} servers"
        if len(bot.guilds) > 1
        else f"I'm in {len(bot.guilds)} server"
    )

    await interaction.response.send_message(message)

server_count() should also return an Embed.

Default operators in validate_operations method do not correlate to their tokens. This isn't necessarily a problem now, or might not ever be an issue. However, operators should utilize a universal token throughout the entire project, the one to be used in the lexer and parser specifically. It should be a simple fix.

Possibly make a method that converts user operators into their tokens. This could be integrated into the lexer somehow.

It may be even nicer to instead of allowed operators, to instead to disallowed operators for simplicity. I want the defaults to include every possible operator and keyword anyway, so it seems cleaner.