Un-usable Dash 'prop' names

[rmarren1]

Since we are now pre-compiling Dash component python classes, we need to make sure those pre-compiled files are compatible with each version of Python we care about.

One source of incompatibility is that we can't use a Python keyword as a class initialization argument. Python keywords change from version to version, and no one version has a superset of the keywords of other versions (e.g. async is a keyword in 3.7 and not 2.7, while exec is a keyword in 2.7 and not 3.7), so this is difficult.

The only reported issue of a Dash component having a prop name that is also a keyword is dash_html_components.Script.async sharing the Python3.7 keyword. This caused a bug which was patched. For now we can release packages that were built with 3.7; however, moving forward we need a way to address this systematically so that people can make components which will be compatible with any version of Python.

I'm open to solutions on how to address this, here are a few of my own ideas:
1. Release versioned PyPi packages
By building classes for each version, we can use the versions keyword.kwlist list to avoid naming class initialization arguments a Python keyword.
This would require us to build more tooling, but I do not think it would be more work on from the users perspective (probably more build time to generate 3+ class files instead of one, but the process is pretty quick).
Prop names that are Python keywords for the particular version the user has installed will not appear in type-ahead/auto-complete

2. Keep a master list of all Python keywords
Avoid naming class initialization arguments values that were ever a Python keyword, so a single class file is compatible with every version of Python
Prop names that were ever a Python keyword will not appear in type-ahead/auto-complete

3. If loading a class file fails, build a new working one at run-time
We still have the logic to generate class files on the fly, which was used previously for every class. We can just use this as a fallback if loading a component class fails.
Prop names that are Python keywords for the particular version the user has installed will not appear in type-ahead/auto-complete, and some IDEs will not support type-ahead for the components which have to use this fallback

[T4rk1n]

Thanks, now I understand what was the problem with the tests.

I think option 2 would be good, we could generate a keyword file for the python versions we support and merge them and use that list. If a new python version come out we just have to generate a new file for that and merge it.

[rmarren1]

I think 2 is the simplest. I don't think keywords change that frequently so this should not be too annoying to maintain.

[rmarren1]

Closed by #450