• 由 Python 的 Ellipsis 到 *, /, *args, **kwargs 函数参数

    calendar Dec 31, 2021   ---   · 5 min read · unpacking args kwargs  ·
    Share on: linkedin copy
    由 Python 的 Ellipsis 到 *, /, *args, **kwargs 函数参数
    早先对 Python *args, **kwargs 参数有所了解，也知道参数列表中的 / 表示 Positional Only， * 很少见。然而在使用 FastAPI 时看到路由函数中表示默认值采用了 ... 的方式又重新激发起我对 Python 函数参数的 *, /, *args, 和 **kwargs 的兴趣。

    如 FastAPI 官方文档 Request Forms and Files 中的
    @app.post("/files/")
    async def create_file(file: bytes = File(...), fileb: UploadFile = File(...), token: str = Form(...)):
    默认值的 File(...), Form(...)， 起初还以为 ... 只是真正意义上的省略号，使用时需传入适当的参数，后来发现 ... 居然是一个 Python 实实在在的内置对象。 Read More

  • FastAPI - 一款新型的 Python Web 框架(对比 Flask)

    calendar Dec 20, 2021   ---   · 5 min read · Flask ASGI  ·
    Share on: linkedin copy
    FastAPI - 一款新型的 Python Web 框架(对比 Flask)
    近日曾想尽办法为 Flask 实现 Swagger UI 文档功能，找到的实现方式基本上是 Flask + Flasgger, 记录在 Flask 应用集成 Swagger UI。然而不断的 Google 过程中偶然发现了一款集成了 Swagger UI 的比 Flask 还好的 Python Web 框架 -- FastAPI 。起初想要在标题中表达的意思大概是 Flask + Swagger = FastAPI, 后来发现 FastAPI 的闪亮点不仅如此，于是乎又找了些 Flask 与 FastAPI 对比的文章读一读，在文后附有链接。

    本文不对 Flask 与 FastAPI 的各个方面对进行对比，本人兴趣依然还是在 FastAPI 的 Swagger UI 功能，以及与 Flask 的 Blueprint 类似的特性。如果要拿 Flask 与 FastAPI 比较的话，应该用 Flask 2.x, 因为它开始支持类似 @app.get 的装饰器，并引入了 async 路由函数。

    Flask 是在 2010 年发布的，它构建于 WSGI(Python Web Server Gateway Interface) 之上的，产品环境中运行需与 uWSGI, Gunicorn 搭配，或用 mod_wsgi 模块与 Apache 集成。因发布较早，所以目前应该有较多的使用者。Flask 2.0 需要 Python 3.6+ 的支持，如果支持 async, 需 Python 3.7+

    FastAPI 发布于 2018 年，构建于 ASGI(Asynchronous Server Gateway Interface) 之上，在 IO 密集型的应用中有更优越的性能。生成环境中配合 ASGI 服务器，如 Uvicorn 或 Hypercorn. FastAPI 最为亮丽的特性是集成了 Swagger UI -- 外加一个福利 ReDoc。FastAPI 需 Python 3.6+ 版本。 Read More

  • Python async, await 的理解与使用

    calendar Dec 17, 2021   ---   · 3 min read · coroutine async  ·
    Share on: linkedin copy
    Python async, await 的理解与使用
    关于 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

  • 逐步理解 Flask 的 Blueprint(蓝本)

    calendar Dec 6, 2021   ---   · 3 min read · Flask  ·
    Share on: linkedin copy
    逐步理解 Flask 的 Blueprint(蓝本)
    Python 的 Flask 框架能让我们快速的建立一个轻量级的 Web 或 REST API。对于小应用由一个 @app 装饰一撸到底就行，当项目稍具规模或要更清晰就要考虑模块化，于是来到了我们今天的话题，首先是

    为什么需要 Blueprint?

    比如说我们一定超级简单的 Flask 应用 main.py 的代码如下：
    1from flask import Flask
2
3app = Flask(__name__)
4
5
6@app.route('/', methods=['GET'])
7def hello():
8    return "hello world!"

    Read More

  • 构建 AWS Lambda Python Docker 镜像

    calendar Nov 8, 2021   ---   · 7 min read · lambda Docker AWS  ·
    Share on: linkedin copy
    构建 AWS Lambda Python Docker 镜像
    AWS 的 Lambda 在 2020-12-01 开始支持用 Docker 镜像存放代码，见 New for AWS Lambda - Container Image Support。AWS Lambda 最初的对发布包的限制是 50M, 解压后(因为执行前需要解压缩)不能超过 250M，对于压缩比小于 1/5 的包来说，要突破 50M 部署包的限制就要用 2018-11-29 推出的层(layer), 即把 Lambda 的依赖可以组织为层，每个 Lambda 可引用最多 5 个层，但最终 Lambda 加上层所解压后的大小仍然有 250 M 的限制。

    对于使用了大量依赖的 Lambda，比如 Python 中用了 Pandas 之类的数学分析包，250M 的大小是不够的，所以才有了 Docker 镜像化的 Lambda, 镜像的大小限制一下蹦到 10G，要构建出一个 10G Lambda 用的 Linux 镜像, 那绝对是个巨兽，至少目前是超越我的想像力，除非往里面塞入大量的业务数据。关于 Lambda 有哪些限制，请参阅 Lambda quotas。

    介绍完 Lambda 引入 Docker 镜像的背景后，本文接下来只关注如何构建一个 Python Lambda 镜像，对于如何部署 Docker 化的 Lambda, 不在本文的范围之内。主要的参考文档为 AWS Lambda 官方的 Deploy Python Lambda functions with container images. Read More

  • 创建和发布自己的 Python 包到 PyPI 上

    calendar Oct 27, 2021   ---   · 6 min read · Python wheel PyPI  ·
    Share on: linkedin copy

    像 Java 可发布包到 Maven 仓库，NodeJS 发布包到 NPM 一样，我们也可以创建自己的 Python 包并发布到 PyPI 仓库中去。或者内部使用的包，只须发布到私有的 Nexus 服务器上。

    本文中的例子将创建一个 Python 包 bounded-executor, 并发布到 PyPI 上。为什么创建这个包呢？原因是直接用 Python 的 ThreadPoolExecutor 或  ProcessPoolExecutor 来提交任务的话，任务的等待队列是没有边界的，这就会造成因提交任务过快而使得内存爆满。本包最为合适的名称应该是 bounded-pool-executor, 可是名字已被他人使用，但此外的实现有所不同，ThreadPoolExecutor 用 Queue(maxsize) 来控制，而 ProcessPoolExceutor 用 BoundedSemaphore 来控制。

    我们以经典的 Python 工程目录结构为例，构建的核心是执行 setup.py 中的 setup 函数，由此来理解 setup 的最主要配置与关键命令做了些什么。这样有助于我们理解其他的 Python 包管理工具的底层行为，从中我们可以对比 poetry 的 build, install, 和 publish 命令。 Read More

  • Python 中创建 PostgreSQL 数据库连接池

    calendar Oct 14, 2021   ---   · 2 min read · PostgreSQL  ·
    Share on: linkedin copy
    Python 中创建 PostgreSQL 数据库连接池
    征战 Java 多年，习惯于使用数据库之前都必须创建一个连接池，即使是单线程的应用，只要有多个方法中需用到数据库连接，建立一两个连接的也会考虑先池化他们。连接池的好处多多，1) 如果反复创建连接相当耗时，2) 对于单个连接一路用到底的应用，有连接池时避免了数据库连接对象传来传去，3) 忘记关连接了，连接池幸许还能帮忙在一定时长后关掉，当然密集取连接的应用势将耗尽连接，3) 一个应用打开连接的数量是可控的

    接触到 Python 后，在使用 PostgreSQL 也自然而然的考虑创建连接池，使用时从池中取，用完后还回去，而不是每次需要连接时创建一个物理的。Python 连接 PostgreSQL 是主要有两个包，py-postgresql 和 psycopg2, 而本文的实例将使用后者。

    Psycopg 在 psycopg2.pool 模块中提供了两个连接池的实现在，它们都继承自 psycopg2.pool.AbstractConnectionPool, 该抽象类的基本方法是

    1. getconn(key=None): 获取连接
    2. putconn(conn, key=None, close=False): 归还连接
    3. closeall(): 关闭连接池中的所有连接

    Read More

  • Python zipfile 只借助内存进行压缩与解压缩

    calendar Oct 13, 2021   ---   · 2 min read · zipfile BytesIO  ·
    Share on: linkedin copy
    Python zipfile 只借助内存进行压缩与解压缩
    Python zipfile 模块压缩与解压缩通常是对物理磁盘文件进行操作，比如参照官方的例子，生成压缩文件的代码是
    with zipfile.ZipFile('spam.zip', 'w') as myzip:
        myzip.write('eggs.txt')
        myzip.write('beef.txt')
    这样就生成了一个包含两个文件的压缩包 spam.zip, 相当于命令 zip spam.zip egges.txt beef.txt 的效果。用  unzip -l spam.zip 命令就能看到其中的两个文件。相应的解压缩的代码如下
    with zipfile.ZipFile('spam.zip', 'r') as myzip:
        print(myzip.filelist())  # 可获得压缩包中的文件列表信息
        myzip.extractall()
    同样是把压缩包 spam.zip 解压缩文件到当前目录中，相当于命令 unzip spam.zip 的效果。

    前面顺便也是熟悉一下 zipfile 模块的常见用法，但有时候我们可能从数据库中，从网络上收到的是字节数据，希望直接处理字节的压缩解压缩，而不借助于中间的磁盘文件，因为通过磁盘文件来处理必须进行善后处理以及可能的资源的竞争，在内存宽裕的情况下效率也是个问题。 Read More

  • Python Poetry 项目中相对路径模块引用的问题

    calendar Oct 9, 2021   ---   · 4 min read · Poetry sys.path  ·
    Share on: linkedin copy
    Python Poetry 项目中相对路径模块引用的问题
    最近一直在折腾 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 .utils import md5              # 同一目录中的 utils 模块
    import .utils
    from ..utils import md5             # 上一级目录中的 utils 模块 (如果 utils.py 在与 app.py 上一级目录的话)
    from my_package.utils import md5  # 绝对引用，总是从包名开始
    注意 from 后面的 . 与 ..，相对路径引用不能直接 import, 如不能 import .utils.md5

    Read More

  • Python 依赖管理与构建工具(CookieCutter, PyScaffold, PyBuilder, Poetry)

    calendar Sep 30, 2021   ---   · 6 min read · CI Poetry  ·
    Share on: linkedin copy
    Python 依赖管理与构建工具(CookieCutter, PyScaffold, PyBuilder, Poetry)
    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 用程序代码来进行安装与构建。关于项目目录布局，有做成项目模板的，然后做成工具来应用项目模板。下面大概浏览一下四个工具的使用

    1. CookieCutter
    2. PyScaffold
    3. PyBuilder
    4. Poetry
    Read More