倒序删除 因为列表总是‘向前移’，所以可以倒序遍历，即使后面的元素被修改了，还没有被遍历的元素和其坐标还是保持不变的
a=[1,2,3,4,5,6,7,8]
print(id(a))
for i in range(len(a)-1,-1,-1):
if a[i]>5:
pass
else:
a.remove(a[i])
print(id(a))
print('-----------')
print(a)
a = [1,2,3,4,5,6,7,8,9,10]
res = [ i for i in a if i%2==1]
print(res)
函数作用域的LEGB顺序
1.什么是LEGB?
L： local 函数内部作用域
E: enclosing 函数内部与内嵌函数之间
G: global 全局作用域
B： build-in 内置作用
python在函数里面的查找分为4种，称之为LEGB，也正是按照这是顺序来查找的
import re
# 方法一
def test(filepath):
distone = {}
with open(filepath) as f:
for line in f:
line = re.sub("\W+", " ", line)
lineone = line.split()
for keyone in lineone:
if not distone.get(keyone):
distone[keyone] = 1
else:
distone[keyone] += 1
num_ten = sorted(distone.items(), key=lambda x:x[1], reverse=True)[:10]
num_ten =[x[0] for x in num_ten]
return num_ten
# 方法二
# 使用 built-in 的 Counter 里面的 most_common
import re
from collections import Counter
def test2(filepath):
with open(filepath) as f:
return list(map(lambda c: c[0], Counter(re.sub("\W+", " ", f.read()).split()).most_common(10)))
魔法方法就是可以给你的类增加魔力的特殊方法，如果你的对象实现(重载)了这些方法中的某一个，那么这个方法就会在特殊的情况下被Python所调用，你可以定义自己想要的行为，而这一切都是自动发生的，它们经常是两个下划线包围来命名的(比如__init___,len),Python的魔法方法是非常强大的所以了解其使用方法也变得尤为重要!
__init__构造器，当一个实例被创建的时候初始化的方法，但是它并不是实例化调用的第一个方法。
new__才是实例化对象调用的第一个方法，它只取下cls参数，并把其他参数传给__init_.
___new__很少使用，但是也有它适合的场景，尤其是当类继承自一个像元祖或者字符串这样不经常改变的类型的时候。
__call__让一个类的实例像函数一样被调用
__getitem__定义获取容器中指定元素的行为，相当于self[key]
__getattr__定义当用户试图访问一个不存在属性的时候的行为。
__setattr__定义当一个属性被设置的时候的行为
__getattribute___定义当一个属性被访问的时候的行为
class MyCls(object):
__weight = 50
@property
def weight(self):
return self.__weight
第一个代表贪心匹配，第二个代表非贪心；
?在一般正则表达式里的语法是指的"零次或一次匹配左边的字符或表达式"相当于{0,1}
而当?后缀于*,+,?,{n},{n,},{n,m}之后，则代表非贪心匹配模式，也就是说，尽可能少的匹配左边的字符或表达式，这里是尽可能少的匹配.(任意字符)
所以：第一种写法是，尽可能多的匹配，就是匹配到的字符串尽量长，第二中写法是尽可能少的匹配，就是匹配到的字符串尽量短。
比如tag>tag>end，第一个会匹配tag>tag>,第二个会匹配。
这个问题被问的概念相当之大， 进程：一个运行的程序(代码)就是一个进程，没有运行的代码叫程序，进程是系统资源分配的最小单位，进程拥有自己独立的内存空间，所有进程间数据不共享，开销大。
线程: cpu调度执行的最小单位，也叫执行路径，不能独立存在，依赖进程存在，一个进程至少有一个线程，叫主线程，而多个线程共享内存(数据共享，共享全局变量),从而极大地提高了程序的运行效率。
协程: 是一种用户态的轻量级线程，协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈，直接操中栈则基本没有内核切换的开销，可以不加锁的访问全局变量，所以上下文的切换非常快。
django:主要是用来搞快速开发的，他的亮点就是快速开发，节约成本，,如果要实现高并发的话，就要对django进行二次开发，比如把整个笨重的框架给拆掉自己写socket实现http的通信,底层用纯c,c++写提升效率，ORM框架给干掉，自己编写封装与数据库交互的框架,ORM虽然面向对象来操作数据库，但是它的效率很低，使用外键来联系表与表之间的查询;
flask: 轻量级，主要是用来写接口的一个框架，实现前后端分离，提考开发效率，Flask本身相当于一个内核，其他几乎所有的功能都要用到扩展(邮件扩展Flask-Mail，用户认证Flask-Login),都需要用第三方的扩展来实现。比如可以用Flask-extension加入ORM、文件上传、身份验证等。Flask没有默认使用的数据库，你可以选择MySQL，也可以用NoSQL。
其WSGI工具箱用Werkzeug(路由模块)，模板引擎则使用Jinja2,这两个也是Flask框架的核心。
Tornado： Tornado是一种Web服务器软件的开源版本。Tornado和现在的主流Web服务器框架(包括大多数Python的框架)有着明显的区别：它是非阻塞式服务器，而且速度相当快。得利于其非阻塞的方式和对epoll的运用，Tornado每秒可以处理数以千计的连接因此Tornado是实时Web服务的一个理想框架
首先是在接入层引入了基于OpenResty的Kong API Gateway, 定制实现了认证, 限流等插件. 在接入层承接并剥离了应用层公共的认证, 限流等功能. 在发布新的服务时, 发布脚本中调用Kong admin api注册服务地址到Kong, 并加载api需要使用插件.
为了解决相互调用的问题, 维护了一个基于gevent+msgpack的RPC服务框架doge, 借助于etcd做服务治理, 并在rpc客户端实现了限流, 高可用, 负载均衡这些功能.
在这个阶段最难的技术选型, 开源的API网关大多用Golang与OpenResty(lua)实现, 为了应对我们业务的需要还要做定制. 前期花了1个月时间学习OpenResty与Golang, 并使用OpenResty实现了一个短网址服务shorturl用在业务中. 最终选择Kong是基于Lua发布的便利性, Kong的开箱即用以及插件开发比较容易. 性能的考量倒不是最重要的, 为了支撑更多的并发, 还使用了云平台提供的LB服务分发流量到2台Kong服务器组成的集群. 集群之间自动同步配置.
饿了么维护一个纯Python实现的thrift协议框架thriftpy, 并提供很多配套的工具, 如果团队足够大, 这一套RPC方案其实是合适的, 但是我们的团队人手不足, 水平参差不齐, 很难推广这一整套学习成本高昂的方案. 最终我们开发了类Duboo的RPC框架doge, 代码主要参考了weibo开源的motan.
领域驱动开发 DDD
在这一架构中我们尝试从应用服务中抽离出数据服务层, 每一个数据服务包含一个或多个界限上下文, 界限上下文类只有一个聚合根来暴露出RPC调用的方法. 数据服务不依赖于应用服务, 应用服务可以依赖多个数据服务. 有了数据服务层, 应用就解耦了相互之间的依赖, 高层服务只依赖于底层服务.
开发Python版本的排名代码需要花费大约三天时间，包括编写代码、单元测试和编写文档。接下来，团队需要大约两周的时间来优化代码。其中一项优化是将分数表达式 (simple_gauss(time)* popular )转换为抽象语法树。该团队还实施了高速缓存逻辑，预先计算了将来某些时间的分数。
相比之下，开发这些代码的Go版本大约花费了四天时间，并且不需要再对其性能实施进一步的优化。虽然Python用来开发初期版本更快，但是整体来说使用Go开发的工作量要小得多。
Go的语言特性使得在优化代码时能够节省大量的时间。使用Python时，我们不得不将表达式解析为抽象语法树，并优化和剖析每一个函数。由于Go比Python快得多，因此我们不需要花太多精力优化代码。最终的结果是，Go代码的执行速度比精心优化的Python代码大约快 40 倍。
用Go来构建Stream系统中的某些组件相比用Python花费了更多的时间。总体来说，开发Go代码要花费更多的精力，但团队用来优化代码性能的时间则更少。
链接： https://blog.csdn.net/ailinyingai/article/details/103989941?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160653401619195283052853%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=160653401619195283052853&biz_