investigate ways to reduce bundle size

[gvwilson]

The plotly.py bundle is approx. 19 Mbyte, which will be a problem for WASM deploys. We should investigate ways to reduce its size.

cf plotly/dash#3050 and #3294

[alexcjohnson]

There are some obvious but fairly small things we could do here:

• get rid of remaining sys.version_info < (3, 7) (can't get rid of the conditional because we want type checking to have that path, but we can get rid of the version check)
• get rid of _plotly_future_ and the stub modules that reference it just to throw an error. We've been in this future for plenty long.
• get rid of unnecessary comments in generated code ... ... ... ...
• Some attribute descriptions are absurdly long, like do we really need to list all the CSS named colors in the docstring for every color? Wouldn't it be a better UX to link to that list at some URL? Similarly fonts no longer need the whole list of what fonts are supported on Chart Studio Cloud.

The bigger thing will be to reduce duplication by subclassing attributes rather than repeating the same definition a million times. Like there are only a few flavors of font attributes - whether they support arrays or not, maybe which sub-attributes they support? Also for error handling seems there are different base classes for traces and layout, but it's still a small list. If we could detect which flavor we have and inherit from a base class the definition should in principle be as simple as:

for single-valued layout fonts like Layout.Font:

from plotly.basedatatypes import BaseLayoutFont as _BaseLayoutFont

class Font(_BaseLayoutFont):
    _parent_path_str = "layout.title"
    _path_str = "layout.title.font"

and for a trace font that supports arrays, like Bar.TextFont:

from plotly.basedatatypes import BaseTraceArrayFont as _BaseTraceArrayFont

class TextFont(_BaseTraceArrayFont):
    _parent_path_str = "bar"
    _path_str = "bar.textfont"

Finally, I wonder if we can get rid of all the explicit *src properties? These only useful to Chart Studio users, and even then I suspect barely anyone uses them. We probably don't want to remove this support entirely, but I wonder if we can just handle them in __setattr__/__getattr__ so they continue to function, without all the extra overhead of explicitly defining them?

[acepace]

I'm going to check about turning all the generated code into a zip file (at setup stage or before) and using zipimport. Then the unnecessary comments are not really interesting and mostly get comrpessed away.