① “低门槛 手把手”python 装饰器(Decorators)原理说明
本文目的是由浅入深地介绍python装饰器原理
装饰器(Decorators)是 Python 的一个重要部分
其功能是， 在不修改原函数(类)定义代码的情况下，增加新的功能
为了理解和实现装饰器，我们先引入2个核心操作：
在这个例子中，函数hi的形参name，默认为'world'
在函数内部，又定义了另一个函数 howdoyoudo，定义这个函数时，将形参name作为新函数的形参name2的默认值。
因此，在函数内部调用howdoyoudo()时，将以调用hi时的实参为默认值，但也可以给howdoyoudo输入其他参数。
上面的例子运行后输出结果为：
这里新定义的howdoyoudo可以称作一个“闭包”。不少关于装饰器的blog都提到了这个概念，但其实没必要给它取一个多专业的名字。我们知道闭包是 函数内的函数 就可以了
当我们进行 def 的时候，我们在做什么？
这时，hi函数，打印一个字符串，同时返回一个字符串。
但hi函数本身也是一个对象，一个可以执行的对象。执行的方式是hi()。
这里hi和hi()有本质区别，
hi 代表了这个函数对象本身
hi() 则是运行了函数，得到函数的返回值。
作为对比，可以想象以下代码
此时也是b存在，可以正常使用。
我们定义2个函数，分别实现自加1， 自乘2，
再定义一个函数double_exec，内容是将某个函数调用2次
在调用double_exec时，可以将函数作为输入传进来
输出结果就是
7
27
同样，也可以将函数作为输出
输出结果为
6
10
有了以上两个核心操作，我们可以尝试构造装饰器了。
装饰器的目的： 在不修改原函数(类)定义代码的情况下，增加新的功能
试想一下，现在有一个原函数
在不修改原函数定义代码的情况下，如果想进行函数内容的添加，可以将这个函数作为一个整体，添加到这样的包裹中：
我们定义了一个my_decorator函数，这个函数进行了一种操作：
对传入的f，添加操作(运行前后增加打印)，并把添加操作后的内容连同运行原函数的内容，一起传出
这个my_decorator，定义了一种增加前后打印内容的行为
调用my_decorator时，对这个行为进行了操作。
因此，new_function是一个在original_function上增加了前后打印行为的新函数
这个过程被可以被称作装饰。
这里已经可以发现，装饰器本身对于被装饰的函数是什么，是不需要考虑的。装饰器本身只定义了一种装饰行为，这个行为是通过装饰器内部的闭包函数()进行定义的。
运行装饰前后的函数，可以清晰看到装饰的效果
我们复现一下实际要用装饰器的情况，我们往往有一种装饰器，想应用于很多个函数，比如
此时，如果我们想给3个print函数都加上装饰器，需要这么做
实际调用的时候，就需要调用添加装饰器的函数名了
当然，也可以赋值给原函数名
这样至少不需要管理一系列装饰前后的函数。
同时，在不需要进行装饰的时候，需要把
全部删掉。
事实上，这样并不方便，尤其对于更复杂的装饰器来说
为此，python提供了一种简写方式
这个定义print1函数前的@my_decorator，相当于在定义完print1后，自动直接运行了
不论采用@my_decorator放在新函数前，还是显示地重写print1 = my_decorator(print1)，都会存在一个问题：
装饰后的函数，名字改变了(其实不止名字，一系列的索引都改变了)
输出结果为:
这个现象的原因是，装饰行为本身，是通过构造了一个新的函数（例子中是wrap_func函数）来实现装饰这个行为的，然后把这个修改后的函数赋给了原函数名。
这样，会导致我们预期的被装饰函数的一些系统变量（比如__name__）发生了变化。
对此，python提供了解决方案：
经过这个行为后，被装饰函数的系统变量问题被解决了
输出结果为
刚才的例子都比较简单，被装饰的函数是没有参数的。如果被装饰的函数有参数，只需要在定义装饰行为时（事实上，这个才更通用），增加(*args, **kwargs)描述即可
之前的描述中可以感受到，对于例子中的装饰行为(前后加打印)，函数被装饰后，本质上是调用了新的装饰函数wrap_func。
因此，如果原函数需要有输入参数传递，只需要在wrap_func（或其他任意名字的装饰函数）定义时，也增加参数输入(*args, **kwargs)，并将这些参数，原封不动地传给待装饰函数f。
这种定义装饰行为的方式更具有普遍性，忘记之前的定义方式吧
我们试一下
输出
这里需要注意的是，如果按照以下的方式定义装饰器
那么以下语句将不会执行
因为装饰后实际的函数wrap_func(虽然名字被改成了原函数，系统参数也改成了原函数)，运行到return f(*args, **kwargs) 的时候已经结束了
因为装饰器my_decorator本身也是可以输入的，因此，只需要在定义装饰器时，增加参数，并在后续函数中使用就可以了，比如
此时装饰器已经可以有输入参数了
输出
你可能发现，为什么不用简写版的方法了
因为以上代码会报错！！
究其原因，虽然
等价于
但是，
并不等价于
这本身和@语法有关，使用@my_decorator时，是系统在应用一个以单个函数作为参数的闭包函数。即，@是不能带参数的。
但是你应该发现了，之前的@wraps(f)不是带参数了吗？请仔细观察以下代码
通过一层嵌套，my_decorator_with_parma本质上是返回了一个参数仅为一个函数的函数(my_decorator)，但因为my_decorator对my_decorator_with_parma来说是一个闭包，my_decorator_with_parma是可以带参数的。（这句话真绕）
通过以上的定义，我们再来看
可以这么理解，my_decorator_with_parma(msg='yusheng')的结果是原来的my_decorator函数，同时，因为my_decorator_with_parma可以传参，参数实际上是参与了my_decorator的（因为my_decorator对my_decorator_with_parma是闭包）， my_decorator_with_parma(msg='yusheng') 全等于 一个有参数参加的my_decorator
因此，以上代码等价于有参数msg传递的
比较绕，需要理解一下，或者干脆强记这种范式：
以上范式包含函数的输入输出、装饰器的输入，可以应对大部分情况了。
实验一下：
输出
以上是一个log装饰器，利用datetime统计了函数的耗时，
并且，装饰器可以进行输出文件操作，如果给出了文件路径，则输出文件，否则就打印。
利用这个装饰器，可以灵活地进行耗时统计
不设置输出文件地址，则打印。运行结果为：
也可以输出到文件
输出结果为
同时在当前目录生成了一个test.log 文件，内容为：
以上的装饰器都是以函数形式出现的，但我们可以稍做改写，将装饰器以类的形式实现。
这个装饰器类Log 上个例子里的装饰器函数log功能是一样的，同时，这个装饰器类还可以作为基类被其他继承，进一步增加功能。
原文 http://www.cnblogs.com/yushengchn/p/15636944.html
② 2022/01/17 python ftplib无法连接服务器及解决
一，问题1：
描述：在使用Python/ftplib程序连接FTP服务器时，遇到问题，能够连接主机A/B的FTP服务器并下载数据，但在连接主机B的FTP服务器时，执行dir/nlst/retrbinary等操作时报错“timeout: timed out”。
分析1(A)：推测问题可能由网络问题引起。经过网络搜索和参考其他文章，了解到TCP传输过程中存在MTU(Maximum Transmission Unit)上限，超过上限的文件传输会拆成多个包分多次发送，可能导致超时问题。发现路由器MTU设置为1492，调整为1472并重启后，问题解决。
分析1(B)：推测问题可能是由程序问题引起，因为FileZilla客户端工作正常。通过谷歌搜索并参考相关文章，了解到设置debug_level=3可以帮助检查问题。发现执行nlst/dir()时返回的是内部IP地址，导致问题发生。分析文章提到这可能是FTP服务器配置错误导致的。解决方法是修改代码以提供处理这种问题的支持，或者找到并修复FTP服务器配置。
二，问题2：
描述：在Jupyter Notebook中使用上述解决方法的代码时，首次运行可以正常执行dir/nlst()，但在第二次运行时，出现了“RecursionError: maximum recursion depth exceeded”的错误。
分析2(A)：通过对比winscp的详细输出信息，找到了问题所在，即FTPLIB无法处理FTP服务器返回的错误内部IP。解决方法是自定义FTPLIB的FTP.makepasv()函数，返回正确的外部IP。
分析2(B)：问题出现在import库后未正确清除内存中的代码，并重新加载。解决方法是在使用importlib.reload()重新加载库后，问题得到解决。
整体方案：在第一次运行后，通过自定义函数替换原FTPLIB.FTP.makepasv()。第二次运行时，如果在同一个名字空间中多次导入相同模块，会导致无限循环问题。需要确保在不同服务器连接时，即使使用相同的客户端，makepasv()返回的IP也可能不一致。