Moving to attrs

[kilacoda-old]

With the release of attrs v21.1.0 with VSCode support and custom init functions, I believe it might be a good idea to reopen discussion on using attrs for all classes in manim (see #7). What are your opinions on this? Should we switch to attrs or keep the library class structure as it is?

[friedkeenan]

I believe something like I described in #787 would be a good direction to move towards, where we have mattribute which is our own custom decorator (that would inherit from property), that we could make specific to our use.

For instance, we could have it so when you set an attribute to None, it automatically sets the attribute to the default value (which would be user-settable), like so:

class MyMobject:
    default_width = 1

    def __init__(self, width=None):
        self.width = width

    @mattribute
    def width(self):
        return self._width

    @width.setter
    def width(self, value):
        # This will receive MyMobject.default_width when the
        # width attribute is set to None
        self._width = value

m = MyMobject()

# Returns 1
m.width

m.width = 2
# Returns 2
m.width

MyMobject.default_width = 3
m.width = None
# Returns 3
m.width

And then additionally, for simple attributes we could just do something like

class MyMobject:
    default_width = 1

    def __init__(self, width=None):
        self.width = width

    width = mattribute("docstring") # Maybe figure out a good interface for type hints too?

which would do the same as the earlier example but more succinctly.

Most of the attributes for mobjects that we're setting are just the arguments to the constructor, which might not describe the object as it is even on init, but even if it does, if the object is changed, then those attributes that were set on init no longer describe the object, and that's confusing for users. Additionally, a not small chunk expect to be able to set attributes and have the object update accordingly.

One way to solve this would be to just not keep around the arguments passed to the constructor, but that poses problems for some internal functions like generate_points, and also I think having some sort of access to the initial arguments is useful for the user, especially since not all mobjects are directly created by the user and so they can't just keep track of the arguments themselves. Another solution would be to store the initial arguments in a config attribute, so like to get the color argument you'd do mob.config.color. This creates a clear separation between attributes that describe the mobject as it is, and just things that were passed to the constructor. It might also clear up confusion about what e.g. axis_config and such arguments mean.

And so, with all that, I'm not sure that class annotations and dataclasses are the best way to go forward. I feel like they'd end up being technical debt that either we'd stick with because it'd be a good amount of effort to rip out and they work "well enough", or we'd end up putting in the effort to rip them out anyways, and I think we should try to go for the best implementation before implementing a middling one