- 本文默认读者对 Python 生成器 有一定的了解，不了解者请移步至生成器 - 廖雪峰的官方网站。
- 本文基于 Python 3.5.1，文中所有的例子都可在 Github 上获得。
学过 Python 的都知道，Python 里有一个很厉害的概念叫做 生成器（Generators）。一个生成器就像是一个微小的线程，可以随处暂停，也可以随时恢复执行，还可以和代码块外部进行数据交换。恰当使用生成器，可以极大地简化代码逻辑。
也许，你可以熟练地使用生成器完成一些看似不可能的任务，如“无穷斐波那契数列”，并引以为豪，认为所谓的生成器也不过如此——那我可要告诉你：这些都太小儿科了，下面我所要介绍的绝对会让你大开眼界。
生成器 可以实现 协程，你相信吗？
解析几何的巅峰 是 向量 那无关过程的狂妄与简洁 映射着大自然无与伦比的美
如何判断两条直线是否相交？
这很容易。平面直线，无非就是两种关系：相交 或 平行。因此，只需判断它们是否平行即可。而直线平行，等价于它们的斜率相等，只需分别计算出它们的斜率，即可做出判断。
但倘若我把“直线”换成“线段”呢——如何判断两条线段是否相交？
这就有些难度了。和 直线 不同，线段 是有固定长度的，即使它们所属的两条直线相交，这两条线段也不一定相交。
也许你会说：分情况讨论不就行了嘛：
的确，从理论上这是一个可行的办法，这也是人们手动计算时普遍采用的方法。
然而，这个方法并不怎么适用于计算机。原因如下：
那么，有更好的方法？
当然有。
直到下午四点，供桌才摆上。
冒着热气的鸡，整只；两尾鱼，张着嘴卧在盘中；一摞柑，愣是叠成了宝塔的形状；此外，还有一包包花花绿绿的零食。一米见方的桌子被塞得满满的，全是贡品。
母亲忙得团团转。本来是不想拜天公的，但转念一想，不是太好，便摆上了。阳光下，热气一直往上冒，往上冒，直到看不见的地方——那里，想必就住着那位神。
看来，这位神一定是个重要人物了——不然，母亲怎会遗忘了其他的几位，而只供奉他一个？
搬家之前，家里可还是住着许多神的：门口有一个，阳台上有一个，厨房有一个，抽屉下有一个，就连洗衣机上也有一个。听母亲说：每一家都有，每一位神，都在守卫着这个家。
神们也不是白干活，也是要吃饭的。不只是过年，每个月中总有那么几天，神们会一起来要吃的。每到这时，母亲便会忙活起来，为他们张罗吃的。好在他们并不挑剔——生的，熟的，速食的，神们都默默地收下了。当然，贡品在屋子里转了一圈，自然又都进到了我们的肚子里。
每换一个地方，母亲便上一炷香，虔诚地跪下来，轻轻地拜两拜，口中念念有词。
接着，她又拉我一起来。
我不懂，她便教我——想着自己想要的事就好了。
我学着样子跪下来，胡乱说了几句，装模作样地拜了两拜，余光却仍盯着那食物。
听母亲说，这是老家带来的习俗。对神的敬畏，在那个古老的地方，说着那古老语言的人们，已经沿袭了很久很久了。
人终是怕神的——以前是，现在也是；中国是，外国也是。神像一群喜欢偷窥的人，在这里，也在那里，在每个角落偷窥着你。你受欺负时，神会给你庇护；你做坏事时，神会予你惩罚。因此，怕神的人，多是善良的。
说是怕神，倒不如说是怕天，敬畏变幻莫测的未知。活物总是怀着对死亡的恐惧，人类也不例外。未知中蕴藏着杀机，使愚昧的人类感到不安，转而求助于那假象中的造物主，那超能力者，那个开着全局视角看戏的“人”，这便成了“神”。神为人类抵挡着未知，人类也因此安分守己，深怕触犯了神，再次被暴露于未知的荒野中。
然而，神正在离去，因为未知正在散去。
但藏在那未知背后的是什么，谁又知道呢？未知的背后仍是未知，现实可以是虚幻，真理也可以是谬误，时间洪流夹带着未知，使任何人都只能屏息，任何人，都不可以妄自尊大。
好在，还有神——尽管神正在离去。
但终究，怕神的人是善良的。
这是源于两年前，当我在做人生中第一个真正意义上的网站时遇到的一个问题。该网站采用前后端分离的方式，由后端的 REST 接口返回 JSON 数据，再由前端渲染到页面上。
同许多初学 Javascript 的菜鸟一样，起初，我也是采用拼接字符串的形式，将 JSON 数据嵌入 HTML 中。开始时代码量较少，暂时还可以接受。但当页面结构复杂起来后，其弱点开始变得无法忍受起来：
+ 和 "。十分容易出错。<template> 标签。这是 HTML5 中新增的一个标签，标准极力推荐将 HTML 模板放入 <template> 标签中，使代码更简洁。为了解决这个问题，我暂时放下了手上的项目，花了半个小时实现一个极简易的字符串模板。
接触过 Django 的同学都应该十分熟悉它的 ORM 系统。对于 python 新手而言，这是一项几乎可以被称作“黑科技”的特性：只要你在 models.py 中随便定义一个 Model 的子类，Django 便可以：
Meta 内部类，并转化成相应的配置信息。对于特殊的 Model（如 abstract、proxy），还要进行相应的转换objects 的 Model 加上一个默认的 Manager开发之余，我也曾脑补过其背后的原理。曾经，我认为是这样的：
启动时，遍历
models.py中的所有属性，找到Model的子类，并对其进行上述的修改。
当初，我还以为自己触碰到了真理，并曾将其应用到实际生产中——为 SAE 的 KVDB 写了一个类 ORM 系统。然而在实现的过程中，我明显感受到了这种方法的丑陋，而且性能并不出色（因为要遍历所有的定义模块）。
那么事实上，Django 是怎么实现的呢？
自古以来我们制造东西的方法都是“自上而下”的，是用切削、分割、组合的方法来制造。然而，生命是自下而上地，自发地建造起来的，这个过程极为低廉。 ——王晋康《水星播种》
这句话揭示了生命的神奇所在：真正的生命都是由基本物质自发构成的，而非造物主流水线式的加工。
那么，如果 类 也有生命的话，对它自己的修饰就不应该由调用者来完成，而应该是自发的。
幸而，python 提供了造物主的接口——这便是 Meta Classes，或者称为“元类”。
原文链接：戳这里
Web 是一种可视化的媒体。绚丽的视觉效果，很大程度上离不开图片文件所作出的贡献。虽然（Whilst）其中的许多效果都可以用 CSS 和 内联 SVG 来实现，互联网上的许多站点仍需要图片文件。
从去年的统计来看，每个站点中，图片平均占了一半的页面体积，并且随着时间的推移，图片体积有持续增加的趋势；就 2014 年而言，图片的大小便增长了 **21%**。
与此同时，互联网终端的种类、数量也在增长。从 72 ppi（市场份额正在下降）到 600 ppi，不同设备的分辨率（resolution）有着天壤之别。
创建能在任何设备中都有着高质量的图片，其实再容易不过了——用 1000 ppi 的质量保存图片，然后就可以不用再理他了（译者注：原文是 call it a day）。生成的图片，即使是在分辨率最高的设备上查看也是十分清晰的（crisp）。但是，在图片质量提升的同时，图片文件的大小也会相应地增加。要知道，页面加载时间可是影响用户体验的首要因素——因此，保证站点能够及时地呈现在用户面前是我们义不容辞（incrumbent）的责任。高质量的图片，即使是在宽带环境下加载也要耗费几十秒，更不用说（let alone）是移动端的设备了——简直就是无法使用。
响应式图片的目的，不是要为设备提供尽可能高质量的图片（这一点，我们很容易做到），而是要为设备提供它所能支持的最高质量的图片，仅此而已（nothing more）。
从这篇指南中，你将了解到响应式图片的工作原理（what works），响应式图片仍然存在的问题和陷阱（pitfall），以及如何将响应式图片运用到网站中。
