CI failing due to typing issues about axelrod

[marcharper]

you suggest that we create an auxiliary class that would be responsible for generating random inputs (regarding the player class) when arguments are optional and not given by the user, and also to be able to mutate default values?

Yes, I'm suggesting that the parameters, how they are randomly generated, and how they mutate would make more sense as a separate class rather than intermingled with the strategy code. You could imagine the Player class asking the auxiliary class:

• if the parameters are sufficiently specified on __init__ (with the derived parameters generated as needed)
• if the parameters have nontrivial mutation options
• to generate a new variant

I haven't thought through all the implications.

This suggestion could also resolve issue #1345 -- the parameter holding class could have a default no-op mutation case (alternatively so could the Player class...). These could be good candidates for using dataclasses or the attrs library, which play nicely with mypy.

Anyway that's separate from the immediate typing issues, just wanted to mention it as something to think about in the context of whether the parameters are truly optional or not, since at least some of them have to be specified.

[marcharper]

In this specific case the arguments are truly optional since the strategy generates a random set of parameters (given the seed) if a non-sufficient set of arguments is given. If we were to specify default options of the correct type it would change this behavior.

However there is a non-trivial collection of which combinations parameters can be specified or not (see the logic in the code here), so each argument isn't truly independently optional. It may be a good idea to better factor out these behaviors at some point into an auxiliary class that handles the parameters and associated logic for generating new values (and mutated existing ones).

[Nikoleta-v3]

However there is a non-trivial collection of which combinations parameters can be specified or not (see the logic in the code here), so each argument isn't truly independently optional.

Yup, you are right.

It may be a good idea to better factor out these behaviors at some point into an auxiliary class that handles the parameters and associated logic for generating new values (and mutated existing ones).

Just to make sure I understood you correctly: you suggest that we create an auxiliary class that would be responsible for generating random inputs (regarding the player class) when arguments are optional and not given by the user, and also to be able to mutate default values?