带您了解 Python 中的生成器和迭代器的文章
3分钟带你玩转Python,用不了多久你也可以成为大佬
生成器(Generators)和迭代器(Iterators)是 Python 中用于处理序列数据的强大工具。它们可以帮助您以更高效和内存友好的方式处理大型数据集,同时提供了更方便的方式来访问和处理数据。它们都可以用于逐个处理序列中的元素,但它们在实现和工作方式上有所不同。
迭代器(Iterators):
迭代器是一个实现了迭代协议的对象,它可以在循环中逐个返回值,而不必将所有值一次性加载到内存中。迭代器具有两个主要方法:
1.__iter__()
方法:返回迭代器对象本身。
2.__next__()
方法:返回序列中的下一个元素。如果没有元素可以返回,会引发 StopIteration
异常。
迭代器通常用于处理大型数据集,使得只有在需要的时候才会从数据源加载数据。
举个例子说明一下:
def my_generator(max_value): current = 0 while current < max_value: yield current current += 1 gen = my_generator(6) for num in gen: print(num)
运行结果如下:
生成器(Generators):
生成器是一种特殊的迭代器,它使用函数来产生序列中的元素。生成器函数使用 yield
关键字来暂停函数执行并产生一个值,然后在需要下一个值时再次恢复执行。这允许您按需生成值,而不必一次性将所有值加载到内存中。生成器在处理大型数据集时非常高效。
举个例子说明一下:
def my_generator(max_value): current = 0 while current < max_value: yield current current += 1 gen = my_generator(6) for num in gen: print(num)
代码说明:
在上面的生成器示例中,my_generator
函数使用了 yield
关键字来暂停函数的执行并生成值。每次循环迭代时,函数会从上次 yield
暂停的位置恢复执行,并继续执行直到下一个 yield
。
运行结果如下:
总结
生成器和迭代器是 Python 中处理序列数据的重要工具,它们在处理大数据集时可以提供显著的性能和内存优势。通过使用生成器和迭代器,您可以更加高效地处理数据,减少内存使用,并提高代码的可读性。
学习与反思
为什么我们要用迭代器和生成器,代码写了那么多不就是一个for循环的事情吗?
迭代器和生成器在处理序列数据时有许多优点,使得它比普通的 for
循环更加灵活和高效。以下是一些迭代器的优点以及与普通 for
循环的比较:
优点:
1.节省内存:迭代器一次只返回一个元素,而不会一次性将整个序列加载到内存中。这对于大型数据集非常有用,可以有效地减少内存占用。
2.懒惰求值(Lazy Evaluation) :生成器迭代器使用惰性求值,只在需要时生成值。这意味着您可以在不需要全部数据的情况下开始迭代,从而提高性能和效率。
3.支持无限序列:生成器可以用于表示无限序列,因为它们按需生成值,而不需要在内存中存储整个序列。
4.可复用性和模块化:通过封装生成器逻辑,您可以创建可重用的、模块化的生成器函数,以便在不同的上下文中使用。
缺点:
1.速度相对较慢:与直接使用列表的 for
循环相比,迭代器可能会稍微慢一些,因为它们需要在每次迭代时执行一些附加操作。
2.不适合索引访问:由于迭代器是按需生成值的,所以无法通过索引访问特定位置的元素,需要从头开始迭代。
3.无法修改序列:迭代器一般是只读的,不能用于修改序列中的元素。
适用场景:
1.当您需要处理大型数据集时,迭代器可以节省大量内存,并提高性能。
2.当您需要按需生成值,或者处理无限序列时,生成器是一个非常好的选择。
3.当您需要创建可复用的、模块化的代码时,生成器函数能够提供更好的组织和抽象。
我该怎么选:
使用迭代器的主要优点是节省内存、支持惰性求值和无限序列,同时也提高了代码的可复用性和模块化。然而,对于需要快速索引和修改的情况,使用普通的 for
循环可能更为方便。在选择使用迭代器还是普通循环时,您应该根据具体的情况和需求进行权衡。
到此这篇关于一文带你了解Python中的生成器和迭代器的文章就介绍到这了,更多相关Python生成器 迭代器内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
推荐阅读
-
探索 Python 中的迭代器和可迭代对象
-
在一篇文章中阅读 Python 生成器和迭代器
-
深入了解迭代器和通用 for 在 Lua 中的使用
-
了解 GAN 中的生成器和判别器更新机制
-
Python 高级 | 5 分钟了解迭代器和生成器,扎实的代码技能
-
带您了解 Python 中的生成器和迭代器的文章
-
Python 中的迭代器和列表解析是如何工作的?
-
带您了解摄像机内部引用外部引用(内部引用和外部引用)的文章
-
[姿势估计] 实践记录:使用 Dlib 和 mediapipe 进行人脸姿势估计 - 本文重点介绍方法 2):方法 1:基于深度学习的方法:。 基于深度学习的方法:基于深度学习的方法利用深度学习模型,如卷积神经网络(CNN)或递归神经网络(RNN),直接从人脸图像中学习姿势估计。这些方法能够学习更复杂的特征表征,并在大规模数据集上取得优异的性能。方法二:基于二维校准信息估计三维姿态信息(计算机视觉 PnP 问题)。 特征点定位:人脸姿态估计的第一步是通过特征点定位来检测和定位人脸的关键点,如眼睛、鼻子和嘴巴。这些关键点提供了人脸的局部结构信息,可用于后续的姿势估计。 旋转表示:常见的旋转表示方法包括欧拉角和旋转矩阵。欧拉角通过三个旋转角度(通常是俯仰、偏航和滚动)描述头部的旋转姿态。旋转矩阵是一个 3x3 矩阵,表示头部从一个坐标系到另一个坐标系的变换。 三维模型重建:根据特征点的定位结果,三维人脸模型可用于姿势估计。通过将人脸的二维图像映射到三维模型上,可以估算出人脸的旋转和平移信息。这就需要建立人脸的三维模型,然后通过优化方法将模型与特征点对齐,从而获得姿势估计结果。 特征点定位 特征点定位是用于检测人脸关键部位的五官基础部分,还有其他更多的特征点表示方法,大家可以参考我上一篇文章中介绍的特征点检测方案实践:人脸校正二次定位操作来解决人脸校正的问题,客户在检测关键点的代码上略有修改,坐标转换部分客户见上图 def get_face_info(image). img_copy = image.copy image.flags.writeable = False image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) results = face_detection.process(image) # 在图像上绘制人脸检测注释。 image.flags.writeable = True image = cv2.cvtColor(image, cv2.COLOR_RGB2BGR) box_info, facial = None, None if results.detections: for detection in results. for detection in results.detections: mp_drawing.Drawing.detection = 无 mp_drawing.draw_detection(image, detection) 面部 = detection.location_data.relative_keypoints 返回面部 在上述代码中,返回的数据是五官(6 个关键点的坐标),这是用 mediapipe 库实现的,下面我们可以尝试用另一个库:dlib 来实现。 使用 dlib 使用 Dlib 库在 Python 中实现人脸关键点检测的步骤如下: 确保已安装 Dlib 库,可使用以下命令: pip install dlib 导入必要的库: 加载 Dlib 的人脸检测器和关键点检测器模型: 读取图像并将其灰度化: 使用人脸检测器检测图像中的人脸: 对检测到的人脸进行遍历,并使用关键点检测器检测人脸关键点: 显示绘制了关键点的图像: 以下代码将参数 landmarks_part 添加到要返回的关键点坐标中。
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。