Adding new pruners

[eldarkurtic]

Hi!
What would be the preferred way to add a new gradual pruner in the existing codebase? I have two options/suggestions, and they both have some pros and cons.

New pruner specification: it's a gradual pruner, it has all properties and methods that current GMPruningModifier, it has some additional properties related specifically to that type of pruning.

1. Creating a new PruningModifier class with its own definitions of properties and methods. Cons: all code from the GMPruningModifier would be duplicated.
2. Adding it as a part of GMPruningModifier class. Triggered by using a specific mask_type and feeding the additional properties from the YAML through kwargs of the __init__ method. Cons: maybe not the clearest solution to parse the additional properties from kwargs; I assume that GM stands for GradualMagnitude which might not be the best naming for the new pruner that is not a magnitude pruner.

Option to discuss: rebrand the current GMPruningModifier to be a base class for all (future) gradual pruning modifiers. Classes that would inherit from it could be: MagnitudePruningModifier, New1PruningModifier, New2PruningModifier...

[markurtz]

Hey @eldarkurtic, my preferred implementation would be abstracting out the common code between the GMPruningModdifier and the new one into a parent class. GM does stand for GradualMagnitude; however, we have considered renaming this to make it more apparent.

Would definitely be good to know what the additional arguments are and how much overlap is there. Could me, you, and @bfineran sync up on this to discuss the planned changes?

[eldarkurtic]

Yes, I would be happy to discuss more about this and sync the planned changes.