14.1 Sentence类第1版：单词序列
从 Python 3.4 开始，检查对象 x 能否迭代，最准确的方法是：调用 iter(x) 函数，如果不可迭代，再处理 TypeError 异常。这比使用 isinstance(x, abc.Iterable) 更准确，因为 iter(x) 函数会考虑到遗留的__getitem__方法，而 abc.Iterable 类则不考虑。
>>> class F():
def __iter__(self):
pass
>>> f = F()
>>> iter(f)
Traceback (most recent call last):
File "<pyshell#6>", line 1, in <module>
iter(f)
TypeError: iter() returned non-iterator of type 'NoneType'
>>> isinstance(f, collections.abc.Iterable)
True
>>> class G():
def __getitem__(self):
pass
>>> g = G()
>>> iter(g)
<iterator object at 0x000001BA5F099A20>
>>> isinstance(g, collections.abc.Iterable)
False
14.3 典型的迭代器
构建可迭代的对象和迭代器时经常会出现错误，原因是混淆了二者。要知道，可迭代的对象有个__iter__方法，每次都实例化一个新的迭代器；而迭代器要实现__next__方法，返回单个元素，此外还要实现__iter__方法，返回迭代器本身。因此，迭代器可以迭代，但是可迭代的对象不是迭代器。
14.4 生成器函数
可迭代对象中：
__iter__方法调用迭代器类的构造方法创建一个迭代器并将其返回：
def__iter__(self):
return SentenceIterator(self.words)
迭代器可以是生成器对象，每次调用__iter__方法都会自动创建，因为这里的__iter__方法是生成器函数：
def__iter__(self):
for word in self.words:
yield word
14.12 深入分析iter函数
内置函数 iter 的文档中有个实用的例子。这段代码逐行读取文件，直到遇到空行或者到达文件末尾为止：
with open('mydata.txt') as fp:
for line in iter(fp.readline, '\n'):
process_line(line)
用print(line)实测发现，必须要有至少一个整个空行，否则到达结尾也不会结束
14 杂谈
。。。。。。。
生成器与迭代器的语义对比
。。。。。。。
第三方面是概念。
根据《设计模式：可复用面向对象软件的基础》一书的定义，在典型的迭代器设计模式中，迭代器用于遍历集合，从中产出元素。迭代器可能相当复杂，例如，遍历树状数据结构。但是，不管典型的迭代器中有多少逻辑，都是从现有的数据源中读取值；而且，调用 next(it) 时，迭代器不能修改从数据源中读取的值，只能原封不动地产出值。
而生成器可能无需遍历集合就能生成值，例如 range 函数。即便依附了集合，生成器不仅能产出集合中的元素，还可能会产出派生自元素的其他值。enumerate 函数是很好的例子。根据迭代器设计模式的原始定义，enumerate 函数返回的生成器不是迭代器，因为创建的是生成器产出的元组。
15.2 上下文管理器和with块
with 语句的目的是简化 try/finally 模式。这种模式用于保证一段代码运行完毕后执行某项操作，即便那段代码由于异常、return 语句或 sys.exit() 调用而中止，也会执行指定的操作。finally 子句中的代码通常用于释放重要的资源，或者还原临时变更的状态。
上下文管理器协议包含__enter__和__exit__两个方法。with 语句开始运行时，会在上下文管理器对象上调用__enter__方法。with 语句运行结束后，会在上下文管理器对象上调用__exit__方法，以此扮演 finally 子句的角色。
15.3 contextlib模块中的实用工具
。。。。。。。。
@contextmanager
这个装饰器把简单的生成器函数变成上下文管理器，这样就不用创建类去实现管理器协议了。
。。。。。。。。
显然，在这些实用工具中，使用最广泛的是 @contextmanager 装饰器，因此要格外留心。这个装饰器也有迷惑人的一面，因为它与迭代无关，却要使用 yield 语句。由此可以引出协程，这是下一章的主题。
Python魔法模块之contextlib
使用 @contextmanager 装饰器时，要把 yield 语句放在 try/finally 语句中（或者放在 with 语句中），这是无法避免的，因为我们永远不知道上下文管理器的用户会在 with 块中做什么。
16.2 用作协程的生成器的基本行为
最先调用 next(my_coro) 函数这一步通常称为“预激”（prime）协程（即，让协程向前执行到第一个 yield 表达式，准备好作为活跃的协程使用）。
图 16-1：执行 simple_coro2 协程的 3 个阶段（注意，各个阶段都在 yield 表达式中结束，而且下一个阶段都从那一行代码开始，然后再把 yield 表达式的值赋给变量）
16.4 预激协程的装饰器
from functools import wraps
def coroutine(func):
""" 装饰器，向前执行第一个yield表达式"""
@wraps(func)
def primer(*args, **kwargs):
gen = func(*args, **kwargs)
next(gen)
return gen
return primer
####################测试用例#############################
@coroutine
def ave():
total = 0.0
count = 0
ave = None
while 1:
term = yield ave
total += term
count += 1
ave = total/count
if __name__ == "__main__":
aa = ave()
#next(aa) 不在需要
print aa.send(1)
print aa.send(2)
print aa.send(3)
=========================================================
(python2.7) C:\Users\ASUS\Desktop>ipython main2.py
1.0
1.5
2.0
作者：你呀呀呀
链接：https://www.jianshu.com/p/813ca3081d3f
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
使用 yield from 句法（参见 16.7 节）调用协程时，会自动预激，因此与示例 16-5 中的@coroutine 等装饰器不兼容。Python 3.4 标准库里的 asyncio.coroutine 装饰器（第18 章介绍）不会预激协程，因此能兼容 yield from 句法。
16.5 终止协程和异常处理
示例 16-7 暗示了终止协程的一种方式：发送某个哨符值，让协程退出。内置的 None 和Ellipsis 等常量经常用作哨符值。Ellipsis 的优点是，数据流中不太常有这个值。我还见过有人把 StopIteration 类（类本身，而不是实例，也不抛出）作为哨符值；也就是说，是像这样使用的：my_coro.send(StopIteration)。
从 Python 2.5 开始，客户代码可以在生成器对象上调用两个方法，显式地把异常发给协程。这两个方法是 throw 和 close。
16.7 使用yield from
第 14 章说过，yield from 可用于简化 for 循环中的 yield 表达式。
在 Beazley 与 Jones 的《Python Cookbook（第 3 版）中文版》一书中，“4.14 扁平化处理嵌套型的序列”一节有个稍微复杂（不过更有用）的 yield from 示例
from collections import Iterable
def flattern(items, ignore_type=(str, bytes)):
for item in items:
if isinstance(item, Iterable) and not isinstance(item, ignore_type):
yield from flattern(item)
else:
yield item
items = [1,2,[3,4,[5,6],7],8]
for item in flattern(items):
print(item)
items = ['www','bai',['du','com']]
for item in flattern(items):
print(item)
图 16-2：委派生成器在 yield from 表达式处暂停时，调用方可以直接把数据发给子生成器，子生成器再把产出的值发给调用方。子生成器返回之后，解释器会抛出StopIteration 异常，并把返回值附加到异常对象上，此时委派生成器会恢复
示例 16-17 展示了 yield from 结构最简单的用法，只有一个委派生成器和一个子生成器。因为委派生成器相当于管道，所以可以把任意数量个委派生成器连接在一起：一个委派生成器使用 yield from 调用一个子生成器，而那个子生成器本身也是委派生成器，使用 yield from 调用另一个子生成器，以此类推。最终，这个链条要以一个只使用 yield表达式的简单生成器结束；不过，也能以任何可迭代的对象结束，如示例 16-16 所示。
任何 yield from 链条都必须由客户驱动，在最外层委派生成器上调用 next(…) 函数或 .send(…) 方法。可以隐式调用，例如使用 for 循环。
16.10 本章小结
本章最后举了一个离散事件仿真示例，说明如何使用生成器代替线程和回调，实现并发。那个出租车仿真系统虽然简单，但是首次一窥了事件驱动型框架（如 Tornado 和asyncio）的运作方式：在单个线程中使用一个主循环驱动协程执行并发活动。使用协程做面向事件编程时，协程会不断把控制权让步给主循环，激活并向前运行其他协程，从而执行各个并发活动。这是一种协作式多任务：协程显式自主地把控制权让步给中央调度程序。而多线程实现的是抢占式多任务。调度程序可以在任何时刻暂停线程（即使在执行一个语句的过程中），把控制权让给其他线程。
17.1.1 依序下载的脚本
sys.stdout.flush()
win下不需要，ubuntu下需要刷新标准输出，才能实时显示
17.1.2 使用concurrent.futures模块下载
import requests
import re
import os
import time
from concurrent import futures
from tqdm import tqdm
# 最大线程数
MAX_TASKS = 10
def download_one(bn):
img = requests.get("http://imgsrc.baidu.com/forum/pic/item/" + bn) # 请求图片原图地址
fpic = open(os.path.join(r".\saito_asuka", bn), "wb") # 新建图片文件
for j in img.iter_content(100000):
fpic.write(j) # 写入文件
fpic.close() # 关闭文件
# bn：basename 图片名
return bn
def save_pic(pic_set):
pic_set = list(pic_set)
workers = min(MAX_TASKS, len(pic_set))
with futures.ThreadPoolExecutor(workers) as executor:
# 适于io密集型任务，如果是cpu密集型任务想绕开GIL：
# with futures.ProcessPoolExecutor() as executor:
# 其默认参数为cpu数量（s.cpu_count()，也是最大线程数）
res = executor.map(download_one, sorted(pic_set))
# 这里res为download_one返回值
# print(list(res))
return len(list(res))
def get_pic(web):
pic = re.compile(r"sign=.*?\.jpg.*?") # 正则表达式
elem = pic.findall(web.text) # findall查询得图片后半地址列表
# 图片名称的集合
pic_set = set()
for i in elem:
basename = i.split("/")[1] # 取得地址中的文件名
if basename not in pic_set:
pic_set.add(basename)
return pic_set
# 此方法监视进度，未被使用
def show(pic_set):
# return pic_set
return tqdm(pic_set)
def download_many(url):
web = requests.get(url)
pic_set = get_pic(web)
return save_pic(pic_set)
def main():
time0 = time.time()
url = "http://tieba.baidu.com/p/5367293540"
count = download_many(url)
cost = time.time() - time0
print("{} pics done in {:.2f}s".format(count, cost))
if __name__ == '__main__':
main()
17.1.3 期物在哪里
executor.submit 方法和 futures.as_completed 函数
executor.map 调用换成两个 for 循环：一个用于创建并排定期物，另一个用于获取期物的结果。
def save_pic(pic_ls):
# 这里发现需要排序，把pic_set改成了pic_ls
pic_ls = pic_ls[:5]
with futures.ThreadPoolExecutor(max_workers=6) as executor:
to_do = []
for bn in sorted(pic_ls):
# submit排定执行时间，返回期物，
# 将表示待执行的操作存入期物列表to_do
future = executor.submit(download_one, bn)
to_do.append(future)
msg = '计划中: {}：{}'
print(msg.format(bn, future))
results = []
for future in futures.as_completed(to_do):
# as_completed在期物运行结束后产出期物(该future不会阻塞)，res获取期物结果(是被操作函数返回值吧)
res = future.result()
msg = '{}结果：{}'
print(msg.format(future, res))
results.append(res)
return len(results)
17.4 实验Executor.map方法
具体情况因人而异：对线程来说，你永远不知道某一时刻事件的具体排序；有可能在另一台设备中会看到loiter(1) 在 loiter(0) 结束之前开始，这是因为 sleep 函数总会释放 GIL。因此，即使休眠 0 秒， Python 也可能会切换到另一个线程。
executor.submit 和 futures.as_completed 这个组合比 executor.map 更灵活，因为 submit 方法能处理不同的可调用对象和参数，而 executor.map 只能处理参数不同的同一个可调用对象。此外，传给 futures.as_completed 函数的期物集合可以来自多个 Executor 实例，例如一些由 ThreadPoolExecutor 实例创建，另一些由 ProcessPoolExecutor 实例创建。