生成器

通过列表生成式，我们可以直接创建一个列表。但是，受到内存限制，列表容量肯定是有限的。而且，创建一个包含100万个元素的列表，不仅占用很大的存储空间，如果我们仅仅需要访问前面几个元素，那后面绝大多数元素占用的空间都白白浪费了。

所以，如果列表元素可以按照某种算法推算出来，那我们是否可以在循环的过程中不断推算出后续的元素呢？这样就不必创建完整的list，从而节省大量的空间。在Python中，这种一边循环一边计算的机制，称为生成器：generator。

要创建一个generator，有很多种方法。第一种方法很简单，只要把一个列表生成式的

[]

()

创建

L

g

[]

()

L

g

我们可以直接打印出list的每一个元素，但我们怎么打印出generator的每一个元素呢？

如果要一个一个打印出来，可以通过

next()

我们讲过，generator保存的是算法，每次调用

next(g)

g

StopIteration

当然，上面这种不断调用

next(g)

for

所以，我们创建了一个generator后，基本上永远不会调用

next()

for

StopIteration

generator非常强大。如果推算的算法比较复杂，用类似列表生成式的

for

比如，著名的斐波拉契数列（Fibonacci），除第一个和第二个数外，任意一个数都可由前两个数相加得到：

1, 1, 2, 3, 5, 8, 13, 21, 34, ...

斐波拉契数列用列表生成式写不出来，但是，用函数把它打印出来却很容易：

注意，赋值语句：

相当于：

但不必显式写出临时变量t就可以赋值。

上面的函数可以输出斐波那契数列的前N个数：

仔细观察，可以看出，

fib

也就是说，上面的函数和generator仅一步之遥。要把

fib

print(b)

yield b

def fib(max):
n,a,b = 0,0,1

while n < max:
#print(b)
yield  b
a,b = b,a+b

n += 1

return 'done'

 这就是定义generator的另一种方法。如果一个函数定义中包含

yield

>>> f = fib(6)
>>> f
<generator object fib at 0x104feaaa0>

 这里，最难理解的就是generator和函数的执行流程不一样。函数是顺序执行，遇到

return

next()

yield

yield

data = fib(10)
print(data)

print(data.__next__())
print(data.__next__())
print("干点别的事")
print(data.__next__())
print(data.__next__())
print(data.__next__())
print(data.__next__())
print(data.__next__())

#输出
<generator object fib at 0x101be02b0>
1
干点别的事
3
8

在上面fib

yield

同样的，把函数改成generator后，我们基本上从来不会用

next()

for

>>> for n in fib(6):
...     print(n)
...
1
3
8

 但是用

for

return

StopIteration

StopIteration

value

>>> g = fib(6)
>>> while True:
...     try:
...         x = next(g)
...         print('g:', x)
...     except StopIteration as e:
...         print('Generator return value:', e.value)
...         break
...
g: 1
g: 1
g: 2
g: 3
g: 5
g: 8
Generator return value: done

关于如何捕获错误，后面的错误处理还会详细讲解。

还可通过yield实现在单线程的情况下实现并发运算的效果　　

#_*_coding:utf-8_*_
__author__ = 'Alex Li'

import time
def consumer(name):
print("%s 准备吃包子啦!" %name)
while True:
baozi = yield

print("包子[%s]来了,被[%s]吃了!" %(baozi,name))

def producer(name):
c = consumer('A')
c2 = consumer('B')
c.__next__()
c2.__next__()
print("老子开始准备做包子啦!")
for i in range(10):
time.sleep(1)
print("做了2个包子!")
c.send(i)
c2.send(i)

producer("alex")

通过生成器实现协程并行运算

迭代器

我们已经知道，可以直接作用于

for

一类是集合数据类型，如

list

tuple

dict

set

str

一类是

generator

yield

这些可以直接作用于

for

Iterable

可以使用

isinstance()

Iterable

>>> from collections import Iterable
>>> isinstance([], Iterable)
True
>>> isinstance({}, Iterable)
True
>>> isinstance('abc', Iterable)
True
>>> isinstance((x for x in range(10)), Iterable)
True
>>> isinstance(100, Iterable)
False

而生成器不但可以作用于

for

next()

StopIteration

*可以被

next()

Iterator

可以使用

isinstance()

Iterator

>>> from collections import Iterator
>>> isinstance((x for x in range(10)), Iterator)
True
>>> isinstance([], Iterator)
False
>>> isinstance({}, Iterator)
False
>>> isinstance('abc', Iterator)
False

生成器都是

Iterator

list

dict

str

Iterable

Iterator

把

list

dict

str

Iterable

Iterator

iter()

>>> isinstance(iter([]), Iterator)
True
>>> isinstance(iter('abc'), Iterator)
True

你可能会问，为什么

list

dict

str

Iterator

这是因为Python的

Iterator

next()

StopIteration

next()

Iterator

Iterator

小结

凡是可作用于

for

Iterable

凡是可作用于

next()

Iterator

集合数据类型如

list

dict

str

Iterable

Iterator

iter()

Iterator

Python的

for

next()

for x in [1, 2, 3, 4, 5]:
pass

 实际上完全等价于：

# 首先获得Iterator对象:
it = iter([1, 2, 3, 4, 5])
# 循环:
while True:
try:
# 获得下一个值:
x = next(it)
except StopIteration:
# 遇到StopIteration就退出循环
break

json & pickle 模块

用于序列化的两个模块

• json，用于字符串 和 python数据类型间进行转换
• pickle，用于python特有的类型 和 python的数据类型间进行转换

Json模块提供了四个功能：dumps、dump、loads、load

pickle模块提供了四个功能：dumps、dump、loads、load

python软件目录结构开发规范

Python语言规范

Python风格规范

为什么要设计好目录结构

"设计项目目录结构"，就和"代码编码风格"一样，属于个人风格问题。对于这种风格上的规范，一直都存在两种态度:

1. 一类同学认为，这种个人风格问题"无关紧要"。理由是能让程序work就好，风格问题根本不是问题。
2. 另一类同学认为，规范化能更好的控制程序结构，让程序具有更高的可读性。

我是比较偏向于后者的，因为我是前一类同学思想行为下的直接受害者。我曾经维护过一个非常不好读的项目，其实现的逻辑并不复杂，但是却耗费了我非常长的时间去理解它想表达的意思。从此我个人对于提高项目可读性、可维护性的要求就很高了。"项目目录结构"其实也是属于"可读性和可维护性"的范畴，我们设计一个层次清晰的目录结构，就是为了达到以下两点:

1. 可读性高: 不熟悉这个项目的代码的人，一眼就能看懂目录结构，知道程序启动脚本是哪个，测试目录在哪儿，配置文件在哪儿等等。从而非常快速的了解这个项目。
2. 可维护性高: 定义好组织规则后，维护者就能很明确地知道，新增的哪个文件和代码应该放在什么目录之下。这个好处是，随着时间的推移，代码/配置的规模增加，项目结构不会混乱，仍然能够组织良好。

所以，我认为，保持一个层次清晰的目录结构是有必要的。更何况组织一个良好的工程目录，其实是一件很简单的事儿。

目录组织方式

关于如何组织一个较好的Python工程目录结构，已经有一些得到了共识的目录结构。在Stackoverflow的这个问题上，能看到大家对Python目录结构的讨论。

这里面说的已经很好了，我也不打算重新造轮子列举各种不同的方式，这里面我说一下我的理解和体会。

假设你的项目名为foo, 我比较建议的最方便快捷目录结构这样就足够了:

Foo/
|-- bin/
|   |-- foo
|
|-- foo/
|   |-- tests/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |
|   |-- __init__.py
|   |-- main.py
|
|-- docs/
|   |-- conf.py
|   |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README

简要解释一下:

1. bin/

   : 存放项目的一些可执行文件，当然你可以起名

   script/

   之类的也行。

2. foo/

   : 存放项目的所有源代码。(1) 源代码中的所有模块、包都应该放在此目录。不要置于顶层目录。(2) 其子目录

   tests/

   存放单元测试代码； (3) 程序的入口最好命名为

   main.py

   。

3. docs/

   : 存放一些文档。

4. setup.py

   : 安装、部署、打包的脚本。

5. requirements.txt

   : 存放软件依赖的外部Python包列表。

6. README

   : 项目说明文件。

除此之外，有一些方案给出了更加多的内容。比如

LICENSE.txt

ChangeLog.txt

下面，再简单讲一下我对这些目录的理解和个人要求吧。

关于README的内容

这个我觉得是每个项目都应该有的一个文件，目的是能简要描述该项目的信息，让读者快速了解这个项目。

它需要说明以下几个事项:

1. 软件定位，软件的基本功能。
2. 运行代码的方法: 安装环境、启动命令等。
3. 简要的使用说明。
4. 代码目录结构说明，更详细点可以说明软件的基本原理。
5. 常见问题说明。

我觉得有以上几点是比较好的一个

README

可以参考Redis源码中Readme的写法，这里面简洁但是清晰的描述了Redis功能和源码结构。

关于requirements.txt和setup.py

setup.py

一般来说，用

setup.py

这个我是踩过坑的。

我刚开始接触Python写项目的时候，安装环境、部署代码、运行程序这个过程全是手动完成，遇到过以下问题:

1. 安装环境时经常忘了最近又添加了一个新的Python包，结果一到线上运行，程序就出错了。
2. Python包的版本依赖问题，有时候我们程序中使用的是一个版本的Python包，但是官方的已经是最新的包了，通过手动安装就可能装错了。
3. 如果依赖的包很多的话，一个一个安装这些依赖是很费时的事情。
4. 新同学开始写项目的时候，将程序跑起来非常麻烦，因为可能经常忘了要怎么安装各种依赖。

setup.py

setuptools的文档比较庞大，刚接触的话，可能不太好找到切入点。学习技术的方式就是看他人是怎么用的，可以参考一下Python的一个Web框架，flask是如何写的: setup.py

当然，简单点自己写个安装脚本（

deploy.sh

setup.py

requirements.txt

这个文件存在的目的是:

1. 方便开发者维护软件的包依赖。将开发过程中新增的包添加进这个列表中，避免在

   setup.py

   安装依赖时漏掉软件包。
2. 方便读者明确项目使用了哪些Python包。

这个文件的格式是每一行包含一个包依赖的说明，通常是

flask>=0.10

pip

pip install -r requirements.txt

关于配置文件的使用方法

注意，在上面的目录结构中，没有将

conf.py

docs/

很多项目对配置文件的使用做法是:

1. 配置文件写在一个或多个python文件中，比如此处的conf.py。
2. 项目中哪个模块用到这个配置文件就直接通过

   import conf

   这种形式来在代码中使用配置。

这种做法我不太赞同:

1. 这让单元测试变得困难（因为模块内部依赖了外部配置）
2. 另一方面配置文件作为用户控制程序的接口，应当可以由用户自由指定该文件的路径。
3. 程序组件可复用性太差，因为这种贯穿所有模块的代码硬编码方式，使得大部分模块都依赖

   conf.py

   这个文件。

所以，我认为配置的使用，更好的方式是，

1. 模块的配置都是可以灵活配置的，不受外部配置文件的影响。
2. 程序的配置也是可以灵活控制的。

能够佐证这个思想的是，用过nginx和mysql的同学都知道，nginx、mysql这些程序都可以自由的指定用户配置。

所以，不应当在代码中直接

import conf

conf.py

main.py

conf.py

settings.py

settings.yaml

对于文档的态度

目录结构中有设

docs/

在普通的项目中，确实没必要写非常详细的文档，我更赞同的是现在的一种流行的风格: "在代码中写文档"。即在写代码的时候，在代码文件里把软件/模块的简要用法写明。简单有用。

小结

Foo/
|-- bin/
|   |-- foo
|
|-- foo/
|   |-- tests/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |
|   |-- __init__.py
|   |-- main.py
|
|-- docs/
|   |-- conf.py
|   |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README

另外，多翻翻经典项目的源码是有好处的，比如在python web开发中比较有名的框架: flask, tornado, django 都是类似的结构。

（PS. 如果有疑问、不同意看法欢迎在评论区讨论；觉得我写得还行，也可以手动点个赞支持一下~）

同系列更多其他的文章: 《创建高质量的Python项目》

插曲：代码风格

若要编写更长更复杂的 Python 代码，是时候谈一谈 编码风格了 。大部分语言都可以有多种（比如更简洁，更格式化）写法，有些写法可以更易读。让你的代码更具可读性，而良好的编码风格对此有很大的帮助。

对Python， PEP 8 已经成为多数项目遵循的代码风格指南；它推动了一种非常易于阅读且赏心悦目的编码风格。每个Python开发者都应该找个时间读一下； 以下是从中提取出来的最重要的一些点：

• 使用 4 个空格的缩进，不要使用制表符。

  4 个空格是小缩进（允许更深的嵌套）和大缩进（易于阅读）之间很好的折衷。制表符会引起混乱，最好弃用。

• 折行以确保其不会超过 79 个字符。

  这有助于小显示器用户阅读，也可以让大显示器能并排显示几个代码文件。

• 使用空行分隔函数和类，以及函数内的大块代码。

• 如果可能，注释独占一行。

• 使用文档字符串。

• 在操作符两边和逗号之后加空格， 但不要直接在左括号后和右括号前加： 

  a = f(1, 2) + g(3, 4)

  .

• 类和函数的命名风格要一致；传统上使用 

  CamelCase

   驼峰风格命名类 而用 

  lower_case_with_underscores

  （小写字母加下划线）命名函数和方法。方法的第一个参数名称应为 

  self

   (查看 初识类 以获得更多有关类和方法的规则)。

• 如果您的代码要在国际环境中使用，不要使用花哨的编码。Python 默认的 UTF-8 或者 ASCII 在任何时候都是最好的选择。

• 同样，只要存在哪怕一丁点可能有使用另一种不同语言的人会阅读或维护你的代码，就不要在标识符中使用非 ASCII 字符。

脚注

文档字符串

模块

函数和方法

下文所指的函数,包括函数, 方法, 以及生成器.

一个函数必须要有文档字符串, 除非它满足以下条件:

1. 外部不可见
2. 非常短小
3. 简单明了

文档字符串应该包含函数做什么, 以及输入和输出的详细描述. 通常, 不应该描述”怎么做”, 除非是一些复杂的算法. 文档字符串应该提供足够的信息, 当别人编写代码调用该函数时, 他不需要看一行代码, 只要看文档字符串就可以了. 对于复杂的代码, 在代码旁边加注释会比使用文档字符串更有意义.

关于函数的几个方面应该在特定的小节中进行描述记录， 这几个方面如下文所述. 每节应该以一个标题行开始. 标题行以冒号结尾. 除标题行外, 节的其他内容应被缩进2个空格.