它提供了一种更方便和习惯的方式来编写和操作查询。它接近Elasticsearch JSON DSL，反映了它的术语和结构。它直接使用定义的类或类似查询集的表达式来暴露从Python的DSL的整个范围。
1.首先导入包
2.连接上搭建好的es服务器 并创建dsl 查询实例
3.接下来就是常用的增删改查的基本使用
3.1 创建索引
首先定义映射关系(也可以不指定，如果想要使用join功能必须手动定义)
3.2创建库
3.3删除库
3.4更新库数据
3.5dsl查询数据
查询1000条数据
根据父级查询子级
根据子级查询父级
将查询结果转化为字典
造轮子是最好的一种学习方式，本文尝试从0开始造个Python Web框架的轮子，我称它为 ToyWebF 。
本文操作环境为：MacOS，文中涉及的命令，请根据自己的系统进行替换。
ToyWebF的简单特性：
下面我们来实现这些特性。
首先，我们需要安装gunicorn，回忆一下Flask框架，该框架有内置的Web服务器，但不稳定，所以上线时通常会替换成uWSGI或gunicorn，这里不搞这个内置Web服务，直接使用gunicorn。
我们创建新的目录与Python虚拟环境，在该虚拟环境中安装gunicorn
在啥都没有的情况下，构建最简单的Web服务，在ToyWebF目录下，创建app.py与api.py文件，写入下面代码。
运行 gunicorn app:app 访问 http://127.0.0.1:8000 ，可以看见 Hello, World! ，但现在请求体中的参数在environ变量中，难以解析，我们返回的response也是bytes形式。
我们可以使用webob库，将environ中的数据转为Request对象，将需要返回的数据转为Response对象，处理起来更加直观方便，直接通过pip安装一下。
然后修改一下API类的 __call__方法 ，代码如下。
上述代码中，通过webob库的Request类将environ对象（请求的环境信息）转为容易处理的request，随后调用handle_request方法对request进行处理，处理的结果，通过response对象返回。
handle_request方法在ToyWebF中非常重要，它会匹配出某个路由对应的处理方法，然后调用该方法处理请求并将处理的结果返回，在解析handle_request前，需要先讨论路由注册实现，代码如下。
其实就是将路由和方法存到self.routes字典中，可以通过route装饰器的形式将路由和方法关联，也可以通过add_route方法关联，在app.py中使用一下。
因为url中可以存在变量，如 @app.route("/hello/{name}") ，所以在匹配时，需要进行解析，可以使用正则匹配的方式进行匹配，parse这个第三方库已经帮我们实现了相应的正则匹配逻辑，pip安装使用一下则可。
这里定义find_handler方法来实现对self.routes的遍历。
了解了路由与方法关联的原理后，就可以实现handle_request方法，该方法主要的路径就是根据路由调度对应的方法，代码如下。
在该方法中，首先实例化webob库的Response对象，然后通过self.find_handler方法获取此次请求路由对应的方法和对应的参数，比如。
它将返回hello方法对象和name参数，如果是 /hello/二两 ，那么name就是二两。
因为route装饰器可能装饰器的类对象，比如。
此时self.find_handler方法返回的hanler就是个类，但我们希望调用的是类中的get、post、delete等方法，所以需要一个简单的判断逻辑，通过inspect.isclass方法判断handler如果是类对象，那么就通过getattr方法获取类对象实例的中对应的请求方法。
如果类对象中没有该方法属性，则抛出该请求类型不被允许的错误，如果不是类对象或类对象中存在该方法属性，则直接调用则可。
此外，如果方法的路由并没有注册到self.routes中，即404的情况，定义了defalut_response方法返回其中内容，代码如下。
如果handle_request方法中调度的过程出现问题，则直接raise将错误抛出。
至此，一个最简单的web服务就编写完成了。
回顾Flask，Flask可以支持HTML、CSS、JavaScript等静态文件，利用模板语言，可以构建出简单但美观的Web应用，我们让TopWebF也支持这一功能，最终实现图中的网站，完美兼容静态文件。
Flask使用了jinja2作为其html模板引擎，ToyWebF同样使用jinja2，jinja2其实实现一种简单的DSL（领域内语言），让我们可以在HTML中通过特殊的语法改变HTML的结构，该项目非常值得研究学习。
首先 pip install jinja2 ，然后就可以使用它了，在ToyWebF项目目录中创建templates目录，以该目录作为默认的HTML文件根目录，代码如下。
首先利用jinja2的FileSystemLoader类将file system中的某个文件夹作为loader，然后初始化Environment。
在使用的过程中（即调用template方法），通过get_template方法获得具体的某个模板并通过render方法将对应的内容传递给模板中的变量。
这里我们不写前端代码，直接去互联网中下载模板，这里下载了Bootstrap提供的免费模板，可以自行去 https://startbootstrap.com/themes/freelancer/ 下载，下载完后，你会获得index.html以及对应的css、jss、img等文件，将index.html移动到ToyWebF/templates中并简单修改了一下，添加一些变量。
然后在app.py文件中为index.html定义路由以及需要的参数。
至此html文件的支持就完成了，但此时的html无法正常载入css和js，导致页面布局非常丑陋且交互无法使用。
接着就让ToyWebF支持css、js，首先在ToyWebF目录下创建static文件夹用于存放css、js或img等静态文件，随后直接将前面下载的模板，其中的静态文件复制到static中则可。
通过whitenoise第三方库，可以通过简单的几行代码让web框架支持css和js，不需要依赖nginx等服务，首先 pip install whitenoise ，随后修改API类的 __init__ 方法，代码如下。
其实就是通过WhiteNoise将self.wsgi_app方法包裹起来，在调用API的 __call__ 方法时，直接调用self.whitenoise。
此时，如果请求web服务获取css、js等静态资源，WhiteNoise会获取其内容并返回给client，它在背后会匹配静态资源在系统中对应的文件并将其读取返回。
至此，一开始的网页效果就实现好了。
web服务如果出现500时，默认会返回 internal server error ，这显得比较丑，为了让框架使用者可以自定义500时返回的错误，需要添加一些代码。
首先API初始化时，初始self.exception_handler对象并定义对应的方法添加自定义的错误
在handler_request方法进行请求调度时，调度的方法执行逻辑时报500，此时不再默认将错误抛出，而是先判断是否有自定义错误处理。
在app.py中，自定义错误返回方法，如下。
custom_exception_handler方法只返回自定义的一段话，你完全可以替换成美观的template。
我们可以实验性定义一个路由来看效果。
Web服务的中间件也可以理解成钩子，即在请求前可以对请求做一些处理或者返回Response前对Response做一下处理。
为了支持中间件，在TopWebF目录下创建middleware.py文件，在编写代码前，思考一下如何实现？
回顾一下现在请求的调度逻辑。
1.通过routes装饰器关联路由和方法 2.通过API.whitenoise处理 3.如果是请求API接口，那么会将参数传递给API.wsgi_app 4.API.wsgi_app最终会调用API.handle_request方法获取路由对应的方法并调用该方法执行相应的逻辑
如果希望在request前以及response后做相应的操作，那么其实就需要让逻辑在API.handle_request前后执行，看一下代码。
其中add方法会实例化Middleware对象，该对象会将当前的API类实例包裹起来。
Middleware.handle_request方法其实就是在self.app.handle_request前调用self.process_request方法处理request前的数据以及调用self.process_response处理response后的数据，而核心的调度逻辑，依旧交由API.handle_request方法进行处理。
这里的代码可能会让人感到疑惑， __call__ 方法和handle_request方法中都有self.app.handle_request(request)，但其调用对象似乎不同？这个问题暂时放一下，先继续完善代码，然后再回来解释。
接着在api.py中为API创建middleware属性以及添加新中间件的方法。
随后，在app.py中，自定义一个简单的中间件，然后调用add_middleware方法将其添加。
定义好中间件后，在请求调度时，就需要使用中间件，为了兼容静态文件的情况，需要对css、js、ing文件的请求路径做一下兼容，在其路径中加上/static前缀
紧接着，修改API的 __call__ ，兼容中间件和静态文件，代码如下。
至此，中间件的逻辑就完成了。
但代码中依旧有疑惑，Middleware类中的 __call__ 方法和handle_request方法其调用的self.app到底是谁？
为了方便理解，这里一步步拆解。
如果没有添加新的中间件，那么请求的调度逻辑如下。
在没有添加中间件的情况下，self.app其实就是API本身，所以 middleware.__call__ 中的self.app.handle_request就是调用API.handle_request。
如果添加了新的中间件，如上述代码中添加了名为SimpleCustomMiddleware的中间件，此时的请求调度逻辑如下。
因为注册中间件时，Middleware.add方法替换了原始Middleware实例中的app对象，将其替换成了SimpleCustomMiddleware，而SimpleCustomMiddleware也有app对象，SimpleCustomMiddleware中的app对象，才是API类实例。
在请求调度的过程中，就会触发Middleware类的handle_request方法，该方法就会执行中间件相应的逻辑去处理request和response中的数据。
当然，你可以通过Middleware.add方法添加多个中间件，这就会构成栈式调用的效果，代码如下。
启动web服务后，其执行效果如下。
一、异同对比选择
1、Python和ruby的相同点：
·都强调语法简单，都具有更一般的表达方式。python是缩进，ruby是类basic的表达。都大量减少了符号。
·都是动态数据类型。都是有丰富的数据结构。
·都具有C语言扩展能力，都具有可移植性，比perl的可移植性更好。也都可以作为嵌入语言。
·都是面向对象的语言，都可以作为大项目的开发工具。
·都有丰富的库支持。
·也有最宽松的版权许可，除了一些工具属于GNU世界。
·都有lisp特色的eval函数，也都能把函数作为参数。
·也有图形界面的ruby的专门编辑器。
·都获得了广泛的c库的支持。如qt、gtk、tk、SDL、FOX等，ruby计划实现SWIG接口。
·都有完善的文档。
相关推荐：《Python视频教程》
2、和python相比ruby的优点：
·具有正则表达式和嵌入html的功能。python也有正则表达式，但没有ruby的应用方便和广泛。python的嵌入html项目才刚起步。ruby还有apache的mod模块。ruby本身也实现和很多unix工具，如racc，doctools。比python更亲近Linux。
·比python功能更完整的面向对象的语法。
·ruby的整个库都是具有类继承的结构。
·他的基本的数据类型和运算符都是可以重载的。
·ruby主要的功能都是通过对象的方法调用来实现的，而不是函数。python也在向这方面发展，但没有ruby做的彻底。
·ruby的类是更规范的单继承，还有接口等概念的实现。
·python可以实现在列表内的条件语句、循环语句，而ruby用“块”的方式来实现这个功能，比python的更灵活，更具有通用性。
·ruby具有类似lisp的彻底的函数方式的条件语句、循环语句等。语句的表达能力更强。
·附带一些unix工具，如racc等。
3、和python相比ruby的不足：
·最大的不足正是因为ruby的强大所引起的。它没有python的简单性好。比较复杂的面向对象语法、“块”语法的引入、正则表达式的引入、一些简写标记都增加了语言的复杂性。
·python的缩进表达方式比ruby的basic的表达方式更让人悦目，ruby程序的满眼的end让人不舒服。当然，ruby认为end的方式比python更先进。
·ruby还没有python的“自省”的能力，没有从程序文件中生成文档的能力。
·ruby没有国际化的支持。国际化支持在ruby的计划中。这是因为ruby的历史比python要短造成的。
·ruby没有类似jython的东西。
4、python和ruby的语言的选择：
从简单的就是好的来说，选python是没错的。python适合寻找简单语言的人，这很可能造成python更流行，因此也有更多的支持。但如果要追求更强大的语法功能，则ruby是好的选择。因为ruby和python的哲学有很多相似的地方，先从python入手，尽量用python，如果python的能力不足了，可以在找ruby。
ruby和python的比较，就像五笔和拼音输入法的比较。拼音作为入门的输入法和长久使用的输入法都没有问题。五笔适合更高要求的情况。如果追求性能的不妨学学ruby。对编程语言感兴趣，想了解各种编程概念的学ruby也会很兴奋。
二、两者各有特点：
1、Python从语法上来说更质朴一些，而Ruby更性感一些
Python的语法相对其他脚本语言来说，没有太多花巧的地方，显得比较死板一点，其实从Python强制代码缩进也可以看出来Guido设计语言的取向。语法死板的一面就是不容易玩出来更性感的东西，比方说Rails这样的框架，另外Python也无法做DSL这样的事情，但是语法死板的另一面就是比较规范，相对来说，更加适应软件开发的工程性要求，更容易组织大规模的团队进行开发。
Ruby的语法非常灵活，Matz设计ruby的出发点也是为了coding for fun，因此可以用ruby玩出来很多花样，运用足够的技巧，可以用Ruby写出来逼近自然语言的DSL，对于程序员来说，玩ruby确实充满了乐趣。Rails能在ruby社区诞生，而不是Python社区诞生绝对和编程语言有直接的关系。不过ruby语法灵活的另一面就是编程实现风格的多样性，这对于大规模团队的协作和管理是一个挑战。
2、Python的解析器实现更成熟，第三方库质量高
Ruby1.9解析器尽管已经有了很大的性能提升和很多新的功能，但是从源代码实现的角度来说，基本上是通过在Ruby1.8源代码上打patch来增加功能的。从源代码的结构来说，Ruby的实现太古老了，Ruby扩展起来比较困难，只能不断打patch。这也是为什么现在Ruby社区涌现出来那么多新的Ruby解析器实现的原因。从很大程度上来说，这制约了Ruby的发展速度。相对而言，Python解析器更成熟，也比较稳定。
在第三方类库的数量上来说，Ruby并不比Python少，但是高性能高质量久经考验的第三方类库Python要明显比Ruby多，事实上很多Ruby的第三方类库都不太成熟，因此这也很大程度上制约了Ruby的发展。
3、Python的应用领域非常广泛，而Ruby目前主要局限在在Web领域
Python应用的领域非常广泛，除了web开发以外，还被广泛用在服务器后端的高性能服务器实现，服务器后端的各种密集运算，全文检索，各种文本处理，系统管理等等，另外桌面应用领域wxPython也是一个很成熟的跨平台GUI框架。对于某些特殊的应用，比方说调用操作系统内核API，Python也可以完成的很好，比方说大量小文件的实时同步方案，就是用Python直接调用linuxKernel的inotify特性来实现的。所以可以说Python是软件开发领域的瑞士军刀，什么事情都可以做。
正是由于Ruby解析器和Ruby类库的制约，Ruby的应用主要局限在Web开发领域，目前Ruby的应用还无法延伸到web开发领域以外的很多地方。据说豆瓣早期就考虑过Ruby on Rails，但是因为Ruby不能做其他事情，而Python可以大包大揽，最后放弃Ruby选择了Python。
4、在Web领域Ruby是王者
随着互联网应用更进一步渗透到软件开发的各个领域，其实web开发占整个软件行业开发的比重也是越来越大。尽管Ruby在其他领域很受制约，但是在Web开发领域就是绝对的王者了。Rails框架的领先程度已经远远甩开了任何一个潜在的竞争对手十万八千里。因此尽管Ruby可能有这样那样的问题，但是说到Web开发，Rails几乎就是无可争议的唯一选择。
而Python尽管十分全面，却偏偏在web开发领域不彰，web框架虽然众多，却没有一个真正可以挑大梁，Django虽然在Python社区比较流行，但很多方面也有缺陷。现在的互联网应用往往都是多种语言混合编程，Ruby在Web以外的缺陷也可以用其他语言来弥补。
5、Python的包管理不如Ruby
尽管Python的第三方类库更高质量更成熟，但是Python社区缺乏Ruby Gem这样一个良好的包管理软件和包发布的网站。因此应用的构建显得不如Ruby那么方便，那么人性化。特别是在类库的版本升级上，就会遇到很多麻烦，不如Ruby Gem那么简单。
不过总的来说，Python和Ruby还是相似度极高的两种编程语言，即使两种编程语言都学习一下也不会浪费太多时间。如果我个人选择的话，会首选用Rails来构建web应用，再根据情况选择Python或者Java处理一些服务器后端的运算。总之，未来还是一个混合编程的时代，我们需要多了解一些编程工具，然后根据需要看菜吃饭才行。
