Move _expand__to_dot's default value to a variable

[TheName]

In DslBase the expand__to_dot variable is by default set to True.
It's troublesome in mappings like mine, where I'm using double underscores regurarly in field names and it would be much easier to just set the default value once and forget about it.

Plus, after creating a query that had it set to False it's hard to use your operands on queries as they're just creating a new one with no option to pass that param.
What's more, even after joining queries 'manually' I can't run them since assignment of a query to Search's query is done by ProxyDescriptor that - in effect - makes it impossible to use your library with field names like mine.

If I'm wrong and I am actually able to run such a query from the Search class - how can I do it? And even if I can; I'd still very much prefer to set the variable once and forget about it instead of passing it each time.

[honzakral]

How would you feel about moving the _expand__to_dot mechanism, including the option to Q and A shortcuts?

This would allow people to write Q("term", person__location__country="CZ") while also allowing for Term(not__nested__field="whatever").

I am not excited about either solution, but I agree that the current situation is not ideal.

Thanks!

[honzakral]

I recently changed the logic to ignore the double underscores when working with raw dicts so you can always do Q({"term": {"not__nested__field": "whatever"}}). Is this acceptable for your use case?

Apologies for taking such long time!

[honzakral]

I also merged the PR since it doesn't really hurt anything and if it makes your life easier.

Again my apologies for the delay!

[TheName]

@honzakral sure, I've been using a workaround in the meantime.

How would you feel about moving the _expand__to_dot mechanism, including the option to Q and A shortcuts?
This would allow people to write Q("term", person__location__country="CZ") while also allowing for Term(not__nested__field="whatever").
I am not excited about either solution, but I agree that the current situation is not ideal.

That's a great suggestion! Was it implemented already or should I make another PR for that?

BTW. Could you please merge this changes to 2.x as well? #809

I'm currently working with older ES version and reimplementing a bigger part of code and I'd rather to use this solution instead of the workaround this time.