关于 Python 中 async, await 关键字的一些知识在去年的一篇 探索 Flask 对 asyncio 的支持 有讲到，一直没在实际上用过它们，所以基本上也就忘干净了。随着 Flask 2 加入了 async 的特性，以及 FastAPI 从一开始支持 async, 又觉得有必要重新温习一下 Python 中如何使用 async, await 关键字了。
注：由于 Flask 支持了 async, 号称 async 化 Flask 的 Quart 项目开始变得无足轻重了。
本文主要的学习材料是在 YouTube 上的一个视频 Fear and Awaiting in Async (Screencast), 其中用 Python REPL 以 Live 的形式展示，对 async, await 关键字循序渐进的讲解。
如今不少语言都支持 async, await 关键字，如 C#, JavaScript, Kotlin, Rust 等，还有今天的主角 Python。而 Java 仍然很重视函数返回值的意义，未支持 async, 只能显式的返回 Future/CompletableFuture, 而且自己控制如何在线程池中执行。 Read More- 征战 Java 多年，习惯于使用数据库之前都必须创建一个连接池，即使是单线程的应用，只要有多个方法中需用到数据库连接，建立一两个连接的也会考虑先池化他们。连接池的好处多多，1) 如果反复创建连接相当耗时，2) 对于单个连接一路用到底的应用，有连接池时避免了数据库连接对象传来传去，3) 忘记关连接了，连接池幸许还能帮忙在一定时长后关掉，当然密集取连接的应用势将耗尽连接，3) 一个应用打开连接的数量是可控的
接触到 Python 后，在使用 PostgreSQL 也自然而然的考虑创建连接池，使用时从池中取，用完后还回去，而不是每次需要连接时创建一个物理的。Python 连接 PostgreSQL 是主要有两个包，py-postgresql 和 psycopg2, 而本文的实例将使用后者。
Psycopg 在 psycopg2.pool 模块中提供了两个连接池的实现在，它们都继承自 psycopg2.pool.AbstractConnectionPool, 该抽象类的基本方法是- getconn(key=None): 获取连接
- putconn(conn, key=None, close=False): 归还连接
- closeall(): 关闭连接池中的所有连接
Read More - Python zipfile 模块压缩与解压缩通常是对物理磁盘文件进行操作，比如参照官方的例子，生成压缩文件的代码是
with zipfile.ZipFile('spam.zip', 'w') as myzip:
这样就生成了一个包含两个文件的压缩包 spam.zip, 相当于命令
myzip.write('eggs.txt')
myzip.write('beef.txt')zip spam.zip egges.txt beef.txt的效果。用unzip -l spam.zip命令就能看到其中的两个文件。相应的解压缩的代码如下with zipfile.ZipFile('spam.zip', 'r') as myzip:
同样是把压缩包 spam.zip 解压缩文件到当前目录中，相当于命令
print(myzip.filelist()) # 可获得压缩包中的文件列表信息
myzip.extractall()unzip spam.zip的效果。
前面顺便也是熟悉一下 zipfile 模块的常见用法，但有时候我们可能从数据库中，从网络上收到的是字节数据，希望直接处理字节的压缩解压缩，而不借助于中间的磁盘文件，因为通过磁盘文件来处理必须进行善后处理以及可能的资源的竞争，在内存宽裕的情况下效率也是个问题。 Read More 
最近一直在折腾 Python 项目，通过对几个 Python 项目依赖管理与构建工具的对比，最后选择了 Poetry。它管理依赖，构建与发布包还是简单的多，不需要处理 setup.py, setup.cfg 和 Makefile 文件, 甚至都不需要了解 wheel 是什么就能往 PyPI 发布包了。
可是，别看 Poetry 的官网一直守护着一副小清新的形像，其实照样处处是坑，其中一个就是与相对引用有关的问题。我们来看下什么样的现像，最后的结论就是：在 Python 中避免使用相对路径引用，因为相对路径的上下文经常在变，然后必要时先执行poetry install, 甚至把入口代码拉到包外头去。
什么是相对引用与绝对路径引用，比如在一个包my_package中有两个模块(Python 文件) app.py 和 utils, app.py 中对 utils 资源的引用可以写成from utils import md5 # 不确定 utils 是一个包还是一个模块，有点像是隐式相对路径模块引用
注意 from 后面的
from .utils import md5 # 同一目录中的 utils 模块
import .utils
from ..utils import md5 # 上一级目录中的 utils 模块 (如果 utils.py 在与 app.py 上一级目录的话)
from my_package.utils import md5 # 绝对引用，总是从包名开始.与..，相对路径引用不能直接 import, 如不能import .utils.md5
Read More- Python 历时这么久以来至今还未有一个事实上标准的项目管理及构建工具，以至于造成 Python 项目的结构与构建方式五花八门。这或许是体现了 Python 的自由意志。不像 Java 在经历了最初的手工构建，到半自动化的 Ant, 再到 Maven 基本就是事实上的标准了。其间 Maven 还接受了其他的 Gradle(Android 项目主推), SBT(主要是 Scala 项目), Ant+Ivy, Buildr 等的挑战，但都很难撼动 Maven 的江湖地位，而且其他的差不多遵循了 Maven 的目录布局。
回到 Python，产生过 pip, pipenv, conda 那样的包管理工具，但对项目的目录布局没有任何约定。关于构建很多还是延续了传统的 Makefile 的方式，再就是加上 setup.py 和 build.py 用程序代码来进行安装与构建。关于项目目录布局，有做成项目模板的，然后做成工具来应用项目模板。下面大概浏览一下四个工具的使用- CookieCutter
- PyScaffold
- PyBuilder
- Poetry
原来用 Java 和 Python 实现过 Avro 转换成 Parquet 格式，所以 Schema 都是在 Avro 中定义的。这里要尝试的是如何定义 Parquet 的 Schema, 然后据此填充数据并生成 Parquet 文件。
本文将演示两个例子，一个是没有层级的两个字段，另一个是含于嵌套级别的字段，将要使用到的 Python 模块有 pandas 和 pyarrow简单字段定义
定义 Schema 并生成 Parquet 文件
Read More
最近本人在 Mac OS X 下安装的 Docker Desktop 经常蹦出要升级的窗口，Skip this update PRO不能用，Install & Restart也总是失败，所以每次只能SNOOZE。原来觉得事有蹊跷，后来才知道这或许与近日吵得沸沸扬扬的 Docker Desktop 收费计划有关。Docker Desktop 是专门为 Windows 和 Mac OS X 定制的，Mac OS X 和 Windows 都是开发人员用的平台。Linux 下可以不用 Docker Desktop，Linux 下 Docker 之间甚至一层窗户纸都没有，实际部署的 Docker 服务也是运行在 Linux 下的。
墙里边微信正在谋划着对聊天记录的云存储收年费，外边是 Docker 在向大公司和开发人员下手，这难道是美国加州版的共同富裕？
Read More- 去年记录过一篇如何使用 Python 的线程，线程池的日志 Python 多线程编程, 需用到 threading.Thread, concurrent.futures.ThreadPoolExecutor。本文可以当作是上一文 Python 多线程编程的姊妹篇。
Python 的多线程受到 GIL(Global Interpreter Lock) 的限制，GIL 是一把加到了 Python 的解释器的锁，使得在任意时刻只允许一个 Python 进程使用 Python 解释器，也就是任意时刻，Python 只有一个线程在运行。
GIL 严重影响了计算密集型(CPU-bound) 的多线程程序，此时的多线程与单线程性能没什么差异，也发挥不了多核的威力。但对 I/O 密集型(I/O-bound) 影响不大，因为 CPU 多数时候是在等待。
为了突破 GIL 的 CPU 密集型程序的限制，可以使用非 CPython 解释器，如 Jython, IronPython 或 PyPy, 更为现实的做法就是使用子进程来替代线程去承担较为繁重的计算任务，因为 GIL 是加在进程上的，所以新的进程有独立的 GIL. Read More - 这几天一直纠缠在如何调用动态库的问题上，先是 Go 语言，而后迁移到 Python 语言。在测试 Python 调用动态库时，出现过 "Segmentation fault (core dumped)" 的问题，本文记录下怎么去寻找线索，找到并解决问题的。
出现 "Segmentation fault (core dumped)" 的原因是多方面的，比如在 C/C++ 语言中- 内存访问越界(数组越界，strcpy, strcat, sprintf, strcmp 等字符串函数读写越界)
- 多线程使用了线程不安全的函数
- 多线程读写的数据未加锁保护
- 非法指针(NULL 指针，随意的指针类型转换
- 堆栈溢出(如大的分配在栈上的局部变量)
用 Python 来调用动态库很大的可能性会是内存访问越界 Read More