[honzakral]

Yes, the goal is similar - to provide a nice API without limiting any of the possibilities. It's much less restrictive (doesn't whitelist parameters) and tries not to force you to learn both Elasticsearch's query language and a DSL on top of by staying close to the original api.

It's currently work in progress but you can already see in tests some of the features like chainable API, composing queries and filters and aggregations:

https://github.com/elasticsearch/elasticsearch-dsl-py/blob/m...

I try to work closely with the fine people at Mozilla currently maintaining ElasticUtils to make sure there is a nice migration path and I don't miss anything obvious. Any feedback would be more than welcome (github, twitter, email, irc #elasticsearch-py, carrier pigeon, ...)!

[andrewgross]

Thanks for sharing. Nice to see an alternative approach for defining these sorts of things.

[honzakral]

Happy to - note that the syntax in the search test is mostly just shortcut (though I fully expect that to be the main interface). You can also use the objects for individual query types: https://github.com/elasticsearch/elasticsearch-dsl-py/blob/m...