KevinHuang的博客

前言我以前写过一些IPython高级用法,还有在组内分享了一期[IPython notebook的分享](http://www.dongwm.com/archives/ji-jiang-zai-bpugfen-xiang/). 今天IPython3被release了.它带来什么可以看一下[release notes](http://ipython.org/ipython-doc/3/whatsnew/version3.html).好吧, 我也没有意识到ipython3来的会这样快. 这多半年来. 我作为一个150个贡献者之一, 见证了IPython的发展. 这是个里程碑的版本.他带来了非常多的变化和新的特性. 今天我来帮大家迁移和解读一些吧.IPython是什么? 本质上它是一个增强版的python交互模式解释器, 所见即所得的执行代码, 查看结果, 也拥有历史记录.我认为这是一个python开发者必备的工具. 我个人依赖ipython常用的功能有: ipython notebook - 一个可以跑的在线可编辑可运行的笔记. 可以测试程序, 执行代码, 当做说明文档, 能帮助不擅长web开发的同学做出很多页面的效果, 支持markdown语法等 自动补全 - 当我import xx的时候 我可以像用zsh一样使用Tab自动补全对应的模块/方法的名字 magic - 它提供很很多magic的函数命令, 比如你可以直接执行ls, pwd等. 还能使用其他shell命令, 调用编辑器等 它能通过?或者??帮我查看代码的注释, 接口参数等等. 它提供很多的配置选择, 可以使用内置/外部插件达到一些其他的功能, 比如autoreload - 你不需要退出ipython就能获得你已经import之后的代码修改后的效果. 它在分布计算, 数据分析上又很好的支持, ipython非常大的 ...

开源了, 开源了喜大普奔.欢迎围观试用: CODE 再来一遍 CODE想直接看效果的可以看 这里 或者拉到最下面.可能很多人有点诧异, CODE不是已经开源了么? 是的, 2014年2月14日CODE的早期版本就开源到了github. 但是后来由于很多原因没有在做下去,今天, 它真的开源了.让我坚持下来的也是我想给外界看到豆瓣工程师文化的结晶, 这是一种情怀, 今天我想说说我和CODE的故事 CODE的意义CODE为什么开源: 希望更多的人可以使用 CODE，希望更多的人可以一起开发 CODE。 - Code Team市面上有gitlab, 有github企业版. 我们折腾一个这样的东西有什么意义呢? 以下是我的看法. CODE是一款豆瓣工程师自发组织, 基于我们自己的需要做出来的. 它是互联网公司程序员的需要而产生的, CODE也曾经给github的同仁们演示, 获得了很高的赞誉. 它并不是github的python克隆版, 但是有些地方却是和github殊途同归. 当产品发展到一定地步, 对这个版本控制工具会有更多的定制化需求, 这个时候会需要二次开发. 假如你是个ruby开发很多的公司, 用gitlab也不算个问题. 但是假如大家用非ruby的语言为主, 那么就很痛苦.ruby虽然在配置管理, web开发上面有一席之位, 但是没有python这么普遍. 同事们的参与局限性就多了很多. 假如你所在公司是python系, 或者爱好python系的, 那么CODE真的是一个很不错的选择. 它是永远免费的, 它是由国内python最大应用公司的工程师们开发, 质量有保证. 看代码的过程中也能学习到一些python的技巧,豆瓣的玩法, 了解豆瓣的开发流程. 我一直觉得轮子是需要造的, 这个过程你能有造轮子的乐趣, 能力得到更多的提高, 而一直在用其他人的东西那么永远只会停留在 ...

####前言在我工作的项目里面使用了mongodb.自然也用到了pymongo.但是它都是在大片的函数里面使用类似于这样的方式 123456import db def test(): ... db.test.find_one() ... 但是问题是在使用完都没有关闭连接,这样多台服务器连接我这台mongodb服务器，在业务高峰期就会占满我的连接, 我当时总结造成这个原因的问题有以下三种: 上面说的用完db不关闭连接而是等着db超时 注意上面的import，其实在import文件的时候数据库连接就已经生成了，没有在需要的时候才创建, 占满我连接的应用其实有很多没有用，浪费了 nginx、uwsgi，celery等应用配置的问题，造成过多的实例，其实根本无益####我今天写的一个封装pymongo和关闭数据库连接的装饰器 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990#/usr/bin/env python # coding=utf-8 """ 1. 封装数据库操作(INSERT,FIND,UPDATE) 2. 函数执行完MONGODB操作后关闭数据库连接 """ from functools import wraps from pymongo.database import Database try: from pymongo import MongoClient except ImportError: ...

今天的文章图片就是这个知乎Live全文搜索的效果了。如果在wifi情况下或者土豪不介意流量的同学可以直接[感受实际使用的动态效果](https://github.com/dongweiming/weapp-zhihulive/blob/master/screenshot/zhihulive.gif) 。在我的《Python Web开发实战》一书中，比较少的介绍到豆瓣自己造的轮子。有读者喷「不够实战」。我显然承认，也很苦闷，今天顺便来吐个槽。我刚工作的时候特别愿意混各种技术会议和活动。经常有一些专家在上面讲：我们自己实现了一个XXX，它有如下多的特性，现在支持了多少个产品线的多少个应用，每天的数据量YYPB，流量ZZ…通篇在讲架构，摆几张高大上的图，甚至能说几个大家不了解的新的玩法都很少，还不断的问坐在下面的领导或者法务：额，这个我能说嘛；那个我能分享么？最最重要的是，他们讲的这些东西大多不是开源的….也基本没有一个可以拿得出手的论文，甚至说白了，如果你正好专注这一部分，会发现它也是根据了FLAG公司的论文在造轮子罢了，说不定造的还不如你。听过之后，也没有收获，都是「别人家」的，甚至有种炫耀的感觉而已，至于有什么苦可能只有他们自己知道吧。我就越来越不愿意参加这种会议了。写书或者博客也是这样。一切东西脱离了公司能提供的基础设施和环境都是空谈，但是这些铺垫说起来就太大了，先不讨论公司有没有授权你在外面说，就是没开源这点就不好弄。说的人都是在虚化的讲一大坨的东西，最多来几个截图之类的（应该还打了马赛克）。等这一大坨东西说的让大家明白了，一本书的厚度肯定不够。但是这些内容呢，只是你为了写书的某一(几)章做铺垫而已，有些内容太专太偏，读者大部分场景下是用不到的，好吧，又得骂娘说你这本书不实用…今天我将基于我过往的实践，以及最近学习asyncio和ES知识完成一个小程序的API服务。看这 ...

前言在豆瓣开源项目里面有个graph-index,提供监控服务器的状态的目录索引,基于graph-explorer.类似衍生物很多,就包括我要说的本文用到的项目.先看看我的测试环境的几个截图 一些关键词说明 graphite-web # graphite组件之一, 提供一个django的可以高度扩展的实时画图系统 Whisper # graphite组件之一, 实现数据库存储. 它比rrdtool要慢，因为whisper是使用python写的，而rrdtool是使用C写的。然而速度之间的差异很小 Carbon # 数据收集的结果会传给它, 它会解析数据让它可用于实时绘图. 它默认可会提示一些类型的数据,监听2003和2004端口 Diamond # 他是一个提供了大部分数据收集结果功能的结合,类似cpu, load, memory以及mongodb,rabbitmq,nginx等指标.这样就不需要我大量的写各种类型,因为它都已经提供,并且它提供了可扩展的自定义类型(最后我会展示一个我自己定义的类型) grafana # 这个面板是基于node, kibana,并且可以在线编辑. 因为是kibana,所以也用到了开元搜索框架elasticsearchPS: 其他工具可以参考这里Tools That Work WithGraphite原理解析我没有看实际全部代码,大概的流程是这样的: 启动Carbon-cache等待接收数据(carbon用的是twisted) 启动graphite-web给grafana提供实时绘图数据api 启动grafana,调用graphite-web接口获取数据展示出来 Diamond定期获取各类要监测的类型数据发给carbon(默认是5分钟,默认一小时自动重载一次配置)实现我这个系统需要做的事情安装graphite相关组件(我这里用的是centos) ...

前言对我来说, 以前每次面试是我审视自己, 检验自己的一种方式. 每次准备面试, 以及被面试官问住的时候才会发现,其实我python我学的还不够好; 工作中也是, 可以从其他的同事那里获得成长. 但是我今天说的是, 我也在自己总结和思考最佳实践这件事.我想很多人都会有意识的去读一些PEP(Python Enhancement Proposals). 了解语言设计者当时的考虑,这些文案也是经过很长时间的讨论最后才实施的.既然想用好这门语言, 必然需要理解设计之美. 比如我听说gvanrossum使用emacs作为编辑器, 我也使用emacs,就是希望我可以更贴近一些python本文根据 The Best of the Best Practices (BOBP) Guide forPython 和 [Khan’s style-guides](https://github.com/Khan/style-guides/blob/master/style/python.md)中对于开发中一些事物的理解和看法, 有出至PEP, 也有一些python界知名开发者,我加入了一些我自己的理解和看法. 价值观“Build tools for others that you want to be built for you.” - KennethReitz (requests等知名库作者)你自己都不想用的东西做出来有什么意义呢? “Simplicity is alway better than functionality.” - Pieter Hintjens(ZeroMQ)我对函数式编程的看法一直是看场景, 甚至于我经常会对比性能, 义无反顾的使用性能最好的, 但是代码又不难懂和繁琐的 “Fit the 90% use-case. Ignore the nay sayers.” - Kenne ...

按照Python3.7的发布时间表，明天Python 3.7.0就发布了，最近各大开源项目都在做3.7相关的调整，之后我还会写文章更详细的介绍Python3.7都带来了什么，敬请关注！Python 3.7是一个比较中庸的版本，我比较关注的是PEP557 和 本文要提到的 PEP562。PEP557是Data Classes，之前我已经在 attrs 和 Python3.7 的dataclasses里面专门介绍了。PEP 562主要做的是什么呢？ Customization of Access to Module Attributes就是能在模块下定义getattr和dir方法，实现定制访问模块属性了。有什么用呢？其实官网已经给出了答案： 弃用某些属性/函数 懒加载(lazy loading)getattr让模块属性的访问非常灵活，我分别举几个例子：弃用某些属性/函数时有时候会修改一些函数或者属性，会写新的版本，旧版本的在一段时间之后会弃用。在大型项目中调用者有很多，不了解业务挨处修改成本很高，通常会在旧版本的函数中加入DeprecationWarning，有3个问题： 使用新的属性是没法提示DeprecationWarning，只能在模块级别加warn 如果找不到属性/函数直接抛错误了，不能做特殊处理 模块下弃用的函数多了，只能在每个函数内部加入warn，再执行新函数逻辑而Python 3.7就没这个问题了： 123456789101112131415161718192021222324# lib.py import warnings warnings.filterwarnings('default') # Python 3.2开始默认会隐藏DeprecationWarning def new_function(arg, other): ...

非常高兴地告诉大家，《Python Web开发实战》要输出到台湾去了。之前由于豆瓣2014年会在台湾举行的原因去了一次台北，非常喜欢这个城市。希望下次去台湾旅行的时候能去诚品看到它啦 版权声明：本文由 董伟明 原创，未经作者授权禁止任何微信公众号和向掘金(juejin.im)转载，技术博客转载采用 保留署名-非商业性使用-禁止演绎 4.0-国际许可协议python

什么是元类？理解元类（metaclass）之前，我们先了解下Python中的OOP和类（Class）。面向对象全称 Object Oriented Programming简称OOP，这种编程思想被大家所熟知。它是把对象作为一个程序的基本单元，把数据和功能封装在里面，能够实现很好的复用性，灵活性和扩展性。OOP中有2个基本概念：类和对象： 类是描述如何创建一个对象的代码段，用来描述具有相同的属性和方法的对象的集合，它定义了该集合中每个对象所共有的属性和方法 对象是类的实例（Instance）。我们举个例子： 123456789In : class ObjectCreator(object): ...: pass ...: In : my_object = ObjectCreator() In : my_object Out: <__main__.ObjectCreator at 0x1082bbef0> 而Python中的类并不是仅限于此： 123In : print(ObjectCreator) <class '__main__.ObjectCreator'> ObjectCreator竟然可以被print，所以它的类也是对象！既然类是对象，你就能动态地创建它们，就像创建任何对象那样。我在日常工作里面就会有这种动态创建类的需求，比如在mock数据的时候，现在有个函数func接收一个参数： 12345In : def func(instance): ...: print(instance.a, instance.b) ...: print(instance.method_a(10)) ...: 正常使用起来传入的instance是符合需求的（有a、b属性和method_a方法），但是当我 ...

前言之前在公众号转载了一篇使用Python模拟登录知乎,使用了目前实现爬虫比较常用的Web登录方式。我以前写爬虫选择的方式是： 如果对方网站有开放平台，满足需求且比较容易获取API权限，优先使用API。 如果网页登录及验证非常容易，甚至都不用登录就可以获取爬取网页，也是可以的。但是Web抓取不是最优先的，因为Web页面结构会改变、登录验证方式也会不断更新，可以感受到层出不断的验证码方式，烦。Web抓取，如果对应的移动适配的页面满足我会优先考虑移动端抓取，限制要少一些。我在知乎回答「你见过哪些令你瞠目结舌的爬虫技巧？」最后提到过：「第二条： 不要只看 Web 网站, 还有移动版、 App 和 H5, 它们的反爬虫措施一般比较少, 所有社交网站爬虫, 优先选择爬移动版。 」，不过这条大家好像都是直接忽略的… 忧伤 当前2种都不好使的时候，虽然没有公开的API，但是只要这个应用有移动版本，就好办….昨天喜闻知乎获得了新一轮的融资，晚上赶紧研究了下通过抓包获取知乎API的方法，分享给大家。由于之前我写的爬虫被对方寄了律师函（像豆瓣、知乎这种胸襟的公司毕竟是少数），读者请不要分享到掘金等平台（知乎可以），小范围传播就好了，感谢！昨晚灵机一动的原因是由于之前在写「我的2016年」的时候，fork了[zhihu-oauth](https://github.com/7sDream/zhihu-oauth)，添加了following接口，跑了个获取参与我的Live的人中有多少关注者的脚本。其实本文并没有超出zhihu-oauth的技术实现。但是我并不想把我的修改提PR合并给上游，因为对一些代码和实现的理解有一些冲突。但是能有本文还是非常感谢zhihu-oauth，它其实就是用知乎API实现的抓取，我本文的提到的技术和代码并没有超过它的范畴。但是还是有一些区别： 代码量。zhihu-oaut ...