Using **kwargs, we can easily pass all the parameters to the User
constructor in a dictionary without requiring the constructor to
contain parameters for the values that both it andEntity need.
Whatever User needs will not be in the **kwargs passed to Entity,
so Entity only gets the leftovers.
This model should help with instances of Pylint too-many-arguments
going forward.
As part of these changes, I've also made it so that User is
instantiated directly using the DB document, as well as the Monster
being instantiated directly using the values from the YAML. This
requires that User/Monster/Entity member names match DB/YAML field names,
though transform functions could easily be created later on to switch
between what the YAML/DB needs and what the code needs. For the time
being, the simplicity is nice as I'm adding new fields, etc., though
the negatives are clear with an approach like this. It should not be
something that stays indefinitely.
Using
**kwargs, we can easily pass all the parameters to theUserconstructor in a dictionary without requiring the constructor to contain parameters for the values that both it andEntityneed. Whatever User needs will not be in the**kwargspassed to Entity, so Entity only gets the leftovers.As part of these changes, I've also made it so that
Useris instantiated directly using the DB document, as well as theMonsterbeing instantiated directly using the values from the YAML. This requires thatUser/Monster/Entitymember names match DB/YAML field names, though transform functions could easily be created later on to switch between what the YAML/DB needs and what the code needs. For the time being, the simplicity is nice as I'm adding new fields, etc., though the negatives are clear with an approach like this. It should not be something that stays indefinitely.