Autogenerate Query classes

[miguelgrinberg]

This change adds a code-generation phase to this client. In this first phase, code generation is applied to two files:

• query.py: All the sub-classes of Query are auto-generated and include docstrings, type hints and a constructor with explicit arguments. All classes have kwargs that are backwards compatible.
• interfaces.py: this is a new file in which all the types that are referenced by attributes of the Query sub-classes are defined.

Things that are not currently implemented but will likely be added later:

• Shortcut properties.
• Properties defined with generics in the specification are given an Any type for now.
• All analyzers are given a Union[str, Dict[str, Any]] type for now.
• Aggregations, Responses, possibly other things will be added in follow-up PRs.

[pquentin]

This is a first review after spending one hour scratching my head on this pull request.

While the inline comments help a lot, there are many things I don't understand yet. We're going to need the review of someone that maintains a typed client as well at some point. @JoshMock and @Anaethelion come to mind, as they have types in their client and are familiar with Python.

[miguelgrinberg]

@pquentin thanks for all the feedback. I have addressed all your points I think, and made changes for each in a separate commit so that you can inspect them separately.

In addition to your feedback, I also added inherited attributes to all classes, which as I mentioned yesterday I forgot to include before. This actually made evident another thing I needed to handle, the AdditionalProperty behavior, which is used in a few of the query classes. This ends up being somewhat similar to a single-key dict, so I had to add this as well. I have to say that all the pain of adding types everywhere is proving very useful with this, because any time I make a mistake or forget something mypy reminds me I have more work to do!

Finally, I've been thinking that the name interfaces.py is odd for Python. Would renaming it to types.py be better? And also, do we want to dump all the queries and types in the root level of the package so that they can be imported directly via from elasticsearch_dsl import X? I recall you indicated you would prefer this way of working with these classes so let me know what you think.

[pquentin]

Here's another round of review. I'm slowly getting to understand this better. Apologies for the reviewing delays, but this is quite daunting!

Finally, I've been thinking that the name interfaces.py is odd for Python. Would renaming it to types.py be better?

Yes, types is better than interfaces.

And also, do we want to dump all the queries and types in the root level of the package so that they can be imported directly via from elasticsearch_dsl import X? I recall you indicated you would prefer this way of working with these classes so let me know what you think.

Yes, I think that would fit the existing design better to dump all classes at the top-level. This will address one issue I have with the split between interfaces/types and queries: I still believe it should be an implementation detail that users don't have to care about.

[pquentin]

Thanks! LGTM.