Python-Package - Aber's BLOG

Python signal

Tue, 12 Dec 2023 00:00:00 +0000

signal 提供了跨平台的信号处理能力，但信号机制在不同系统上却有很大的差异。Python 没有处理一些本可以处理的不同，于是给使用者留下了一点隐藏的问题。

信号的跨平台差异

`SIGINT`/`SIGTERM`

这是两个常常出现的信号，它们的处理函数往往被加入进程退出的程序。在 Unix 和 Windows 上都可以给它们注册对应的信号处理函数，发送却完全不同。

在 Windows 上给一个进程发送 SIGINT 信号，你应该使用的是 signal.CTRL_C_EVENT，而不是像在 Unix 上一样使用 signal.SIGINT。虽然你可以在 Windows 上调用 os.kill(pid, signal.SIGINT)，但它没有你想要的作用。

而 SIGTREM 虽然在 Windows 上被定义了，但只允许进程使用 raise（注意不是 Python 的 raise 语法）给自己抛出。这意味着你无法让一个进程给另一个进程发送 SIGTERM 信号来触发对应的处理函数。在 Windows 上，Python 进程想给本进程发送一个 SIGTERM 信号可以使用 signal.raise_signal(signal.SIGTERM)。

`SIGBREAK`

这是一个 Windows 上独有的信号，由 CTRL+BRAEK 键触发，它类似于 CTRL+C 触发的 SIGINT，区别在于 SIGINT 的默认处理程序是抛出一个 KeyboardInterrupt 异常。

你可以通过 os.kill(pid, signal.CTRL_BREAK_EVENT) 的方式向共享同一个控制台的进程发送 SIGBREAK 信号。

当你在 Windows 控制台使用 CTRL+BRAEK 或 CTRL+C 触发对应的信号时要注意，这些信号会传递到与控制台连接的所有控制台进程。

其他信号

除了上述三个信号外，SIGILL/SIGSEGV/SIGABRT 也是 Windows 上支持的信号，但一般来说它们并不需要被用户程序处理。

Windows 平台只有这六种信号，其他信号无需考虑 Windows 平台的兼容性，使用起来也较为简单，不多赘述。

注册信号处理函数

在 C 语言里编写信号处理逻辑，当信号被处理过一次之后，需要重新注册信号处理函数。而在 Python 里不需要，因为 Python 替你重新注册了。

对同一个信号多次注册处理函数时，Python 只会留下最后一次注册的处理函数。这里就存在一个小技巧，比如处理 SIGINT 信号的时候，用户不停按 Ctrl+C 应该是非常急切的想要关闭。那么第一次触发信号之后，我们可以注册一个新的信号处理函数用于处理快速退出。

import signal


def f0(signum, frame):
    print("Interrupted")
    signal.signal(signal.SIGINT, lambda signum, frame: print("SIGINT"))


signal.signal(signal.SIGINT, f0)

while True:
    import time

    time.sleep(1)

Python asyncio

Fri, 08 Dec 2023 00:00:00 +0000

asyncio 模块里给了用户三个类型，Future、Task 以及 Handle。Python 语言本身提供了 Coroutine 类型。

要理解 asyncio 这个模块，就要从这四个类型的关系入手。

`Coroutine`

这是一个老生常谈的类型。它就是对 Generator 类型的一种封装，在较早版本的 Python 里你可以通过一个装饰器将生成器函数转换为协程函数。

通过 .send() 函数可以驱动一个 Coroutine 执行到下一个切换点，这个切换点是层层 await 语句最终等待的 Awaitable 对象 __await__ 方法的 yield 点。

用一段代码来展示如何不使用 loop 去执行并获取一个 Coroutine 对象的返回值。可以尝试修改 while True 下的 c.send 发送的变量、yield 和 return 值并观察这段代码的输出变化。

class Awaitable:
    def __await__(self):
        x = yield "yield"
        print(f"{x=}")
        return "return"


async def f():
    print("f")
    return await Awaitable()


c = f()
count = 0

try:
    r = c.send(None)
    print(f"{count}. Send {r=}")
    count += 1

    while True:
        r = c.send(None)
        print(f"{count}. Send {r=}")
        count += 1
except StopIteration as exc:
    print("Return", exc.value)
finally:
    c.close()

既然 Coroutine 只是一个特殊的生成器对象，那通过 asyncio.new_event_loop 创建的 loop 是如何知道有哪些协程对象需要被调用 .send() 的？于是在这里我们就需要 Task 来上场了。

`Task`

要将一个 Coroutine 对象加入 loop，就需要使用 loop.create_task 方法，它会通过一个 Coroutine 对象创建一个 Task 对象。

在 Task 对象的 __step_run_and_handle_result 方法里可以看到这几行代码，让人熟悉的 .send 和 exc.value。

coro = self._coro
try:
    if exc is None:
        result = coro.send(None)
    else:
        result = coro.throw(exc)
except StopIteration as exc:
    if self._must_cancel:
        self._must_cancel = False
        super().cancel(msg=self._cancel_message)
    else:
        super().set_result(exc.value)
......

拥有了 Coroutine 和 Task 两个对象还不够，因为程序终究是要与网卡、磁盘或者其他设备进行交互的。在过去，往往都是采用回调函数的方式来编程，这种方式会导致代码的执行顺序不断的被各种回调函数打断，非常不利于阅读。这也是 asyncio 被创造的原因。于是就需要 Future 对象来构建 Coroutine 和现实世界的桥梁。

`Future`

Future 实现了 __await__ 方法让它可以被 Coroutine 使用 await 进行等待；又实现了 set_result/set_exception 方法用于回调设置返回结果。

def __await__(self):
    if not self.done():
        self._asyncio_future_blocking = True
        yield self  # This tells Task to wait for completion.
    if not self.done():
        raise RuntimeError("await wasn't used with future")
    return self.result()  # May raise too.

注意到这里有这样一行代码 self._asyncio_future_blocking = True，从名字不难看出它的特殊意义。回到 Task.__step_run_and_handle_result 方法里可以看到对包含 _asyncio_future_blocking 属性的对象进行了特殊处理：如果这个属性为真，也就意味着 Future 没有被设置值，_asyncio_future_blocking 被设置为了 False，并且调用了 add_done_callback 追加回调函数，让这个 Future 在完成后调用 Task.__wakeup 来设置 Task 的结果。

def __step_run_and_handle_result(self, exc):
    ......
    result._asyncio_future_blocking = False
    result.add_done_callback(
        self.__wakeup, context=self._context)
    self._fut_waiter = result
    if self._must_cancel:
        if self._fut_waiter.cancel(
                msg=self._cancel_message):
            self._must_cancel = False
    ......

而 Future.add_done_task 里是这样处理回调函数的：如果 Future 已经被设置了结果，就调用 loop.call_soon，如果没有设置结果，就加入 _callbacks 列表里。而在 Future 的 set_result 和 set_exception 方法里都调用了 self.__schedule_callbacks()，__schedule_callbacks 只做了一件事——让之前设置的回调函数都仅被 loop.call_soon 调用一次。

def add_done_callback(self, fn, *, context=None):
    """Add a callback to be run when the future becomes done.

    The callback is called with a single argument - the future object. If
    the future is already done when this is called, the callback is
    scheduled with call_soon.
    """
    if self._state != _PENDING:
        self._loop.call_soon(fn, self, context=context)
    else:
        if context is None:
            context = contextvars.copy_context()
        self._callbacks.append((fn, context))

def __schedule_callbacks(self):
    """Internal: Ask the event loop to call all callbacks.

    The callbacks are scheduled to be called as soon as possible. Also
    clears the callback list.
    """
    callbacks = self._callbacks[:]
    if not callbacks:
        return

    self._callbacks[:] = []
    for callback, ctx in callbacks:
        self._loop.call_soon(callback, self, context=ctx)

loop.call_soon 的功能很简单：把函数对象和参数加入 loop 的待执行队列里，并返回一个 Handle 对象。

`Handle`

Handle 对象是一个非常简单的对象，它类似于 functools.partial，是对函数与参数的绑定。并且提供了 cancel 函数用于指示 loop 不要执行这个 Handle。

是的，到这里终于提到了 loop 执行某段代码。Handle 对象才是 loop 唯一实际接触并执行的对象。

在 Task 初始化函数里能看到这样一行代码，这就是 Task 被创建后立刻在 loop 里执行的原因。

def __init__(self, coro, *, loop=None, name=None, context=None,
                 eager_start=False):
    ......
    self._loop.call_soon(self.__step, context=self._context)
    ......

Loop

在 loop.run_forever() 里有一个 while True 不断的执行 loop._run_once()。

def run_forever(self):
    """Run until stop() is called."""
    try:
        self._run_forever_setup()
        while True:
            self._run_once()
            if self._stopping:
                break
    finally:
        self._run_forever_cleanup()

通过 _run_once 的函数注释不难看出这个函数的工作就是调用各种被安排的 Handle 对象。在其中它通过 self._process_events(self._selector.select(timeout)) 来检查可以进行读写的描述符安排对应的 Handle 到可执行的队列中。

def _run_once(self):
    """Run one full iteration of the event loop.

    This calls all currently ready callbacks, polls for I/O,
    schedules the resulting callbacks, and finally schedules
    'call_later' callbacks.
    """
    ......

loop.run_until_complete 和 asyncio.run 是对 loop.run_forever 的封装，通过把 loop.stop() 添加到回调函数里来达到执行完协程后跳出 run_forever 死循环的目的。

综述

Future 是对回调的封装，让回调的结果可以被 Coroutine 使用 await 等待。Task 是对 Coroutine 的封装，让一个 Coroutine 的执行过程可以被拆解为一个个 Handle 对象加入 loop 中执行。

在代码实现上 Task 继承了 Future，这对理解整个 asyncio 的结构造成了一些误会（在几年前我刚学习 asyncio 时看过很多文章吐槽 Task 继承 Future）。但其实这一继承只是为了让 Task 复用 Future 的 await 方法，并不是说明 Future 和 Task 这两个概念本身是继承关系。

同步阻塞

很多新手在使用 asyncio 时会有一种误区，认为把原来的函数改成 async def 就获得了神奇的性能提升。但看完本文之后你应该知道，并不会。

asyncio 所有的代码依旧在同一个线程里执行，如果你的 async def 函数里没有 await，整个函数甚至会一次性全部执行完。而在你的 async def 里只要有任何一点阻塞的部分，整个 loop 就会在这儿停顿。不仅不会提升性能，反而是一个负优化。

如果你真的需要使用 asyncio 而又难以改造代码里的阻塞函数时，可以使用 asyncio.to_thread 把阻塞的同步函数丢进线程池中执行。

asyncio 与 kafka

Tue, 21 Jun 2022 02:31:52 +0000

aiokafka

Python 开发里使用的异步 kafka 客户端，大多是 aiokafka，因为它是目前 Python 社区里唯一一个直接支持 asyncio 的 kafka 客户端库。

但这个库有个大问题，也就是 [Producer] Performance drop when 'send' is called from multiple Futures #528 这个 issue 里提到的，当多个协程（一般是 Web 服务的接口里）并发的推送数据时，CPU 占用率会变得异常的高。由于需要快速恢复业务，所以我当时很快写好一段代码去打补丁。在接口里仅调用 push_message，通过一个内存态的队列把消息按照顺序发送出去。

import asyncio

from loguru import logger
from indexpy import HTTPException

from .mq import get_kafka_client

push_queue: asyncio.Queue[
    tuple[asyncio.Event, tuple[str, bytes, bytes]]
] = asyncio.Queue(1000)


async def _real_push():
    while not push_queue.empty():
        event, (topic, value, key) = await push_queue.get()
        try:
            await get_kafka_client().send_and_wait(topic=topic, value=value, key=key)
        except Exception as e:
            logger.error(f"Failed to push message to Kafka: {e}")
        finally:
            event.set()


worker: asyncio.Task | None = None


async def push_message(topic: str, value: bytes, key: bytes) -> None:
    """
    Push a message to a Kafka topic.
    """
    event = asyncio.Event()
    await push_queue.put((event, (topic, value, key)))
    global worker
    if worker is None:
        worker = asyncio.create_task(_real_push())
    if worker.done():
        worker = asyncio.create_task(_real_push())
    await event.wait()

confluent-kafka-python

过了很久之后我终于有时间寻找别的解决方案。confluent-kafka-python 这个 librdkafka 的 Python 包装几乎是唯一选择了。因为看起来还算可靠的 Python kafka 客户端一共就三个，纯 Python 实现的同步客户端 kafka、纯 Python 实现的异步客户端 aiokafka 以及这个库。

由于 librdkafka 是基于后台线程的回调设计，对 Python、Rust 这种拥有无栈协程的语言来说很容易就接入协程代码中。一个拥有线程保活能力的 asyncio 生产者代码如下。由于在这之前我就将性能瓶颈服务使用 Rust 重写，剩下的代码其实对并发要求并不高所以并没有做性能测试，但我所使用的 rdkafka 也是对 librdkafka 的封装，和如下代码的性能差异应当不会太大。

class AIOProducer:
    def __init__(self, bootstrap_servers: str, loop=None):
        self._loop = loop or asyncio.get_running_loop()
        self._producer = confluent_kafka.Producer({
            "bootstrap.servers": bootstrap_servers,
        })
        self._cancelled = False
        self._count = 0
        self._init_poll_thread()

    def _init_poll_thread(self):
        if hasattr(self, "_poll_thread") and self._poll_thread.is_alive():
            return
        self._poll_thread = Thread(target=self._poll_loop, daemon=True)
        self._poll_thread.start()

    def _poll_loop(self):
        while not self._cancelled:
            self._producer.poll(0.1)

    def close(self):
        self._cancelled = True
        self._poll_thread.join()
        self._producer.flush()

    async def produce(self, topic: str, value: bytes | str, key: bytes | str) -> str:
        result = self._loop.create_future()

        def ack(err, msg):
            if err:
                self._loop.call_soon_threadsafe(
                    result.set_exception, confluent_kafka.KafkaException(err)
                )
            else:
                self._loop.call_soon_threadsafe(result.set_result, msg)

        self._count += 1
        self._producer.produce(topic, value, key, on_delivery=ack)
        if self._count >= 256:
            self._count = 0
            self._init_poll_thread()
        return await result

PDM 使用精要

Sun, 31 Oct 2021 16:00:00 +0000

PDM 是一个新的 Python 包管理工具，它的作者是 PyPa 成员、Pipenv 目前主要的维护者之一。在我许久的使用过程里，深觉这个工具比目前出现的任何其他 Python 包管理工具都好用。但是不能说它是 Python 界的 NPM，因为有些功能 NPM 都没有，唯一可惜的是没有被 Guido 钦定，不然可以说 NPM 是 node.js 的 PDM 了。

安装方式一如既往，只需要 pipx install pdm 就行。

PEP-582

PEP-582 是比较新的一个 PEP 规范，它约束了 Python 本地包存放的位置——__pypackages__。如果使用过 node.js 的人可能会更加明白一点，因为 __pypackages__ 就像是 Python 版本的 node_modules。

而 PDM 默认情况下就是使用这一标准来存储、导入本地包。你只需要使用 pdm --pep582 就可以在 Windows 上直接让 Python 能直接从 __pypackages__ 寻找需要导入的包；在其他系统上则需要把 pdm --pep582 输出的结果追加到自己的 bashrc 里，我相信 Linux 用户都是能力出众的极客，所以不展开 bashrc 这种小事。

不过你需要注意，pdm --pep582 只能让 Python 执行时能够顺利的 import 到需要的包，但却不能让操作系统知道你需要用安装到 __pypackages__ 的可执行文件，故而哪怕你激活了 pdm --pep582，在运行一些命令时你仍然需要把 pdm run 加在命令之前来执行——就像 npm run 一样。

由于此规范太过于新，所以各编辑器并没有自带支持，你需要按照 pdm 文档里的方式去配置。

此外，这并不是本文的重点，如果你有兴趣了解更深，可以看 PDM 作者本人的相关博客——PEP 582 的开发日志(续)

pdm init

按照传统，还是初始化配置，跟着交互式命令输入即可。

如果你是从 poetry 迁移过来的，那么在最后一步 PDM 会问你是不是要从 Python-Poetry 导入信息，可以一键格式转化。这个功能虽然还是有一点瑕疵，有几个字段转换不太正常（不知道现在修了没）不过无伤大雅，重要信息都无损的转换到 pdm 所需的格式了。

pdm add && remove

基本用法与其他管理工具相同，pdm add baize 这种格式就可以安装一个 Python 包了，移除同理。

但 pdm 别出心裁地增加了一个非常好用的功能——分组。以 baize 为例，包必须的依赖自然不必多说，开发时的依赖则非常多，而诸如编译所需的包、构建文档所需的包在正常开发里其实又用不到。

如果你用的是 poetry 那就没办法了，你只能 poetry add package_name --dev 统一划分到开发以来里。而 PDM 允许你使用 pdm add -dG docs package_name 这样的选项在开发依赖里分组，比如 -G docs 是指分到 docs 组，也就是构建文档所需地依赖。

poetry add --dev 这样加进去的开发依赖，可以用 package_name[dev] 来安装，真正的安装时可选依赖你却只能手动修改 pyproject.toml 来划分。而 PDM 做到了真正的开发依赖隔离，构建出来的包是不会携带任何通过 pdm add -d 命令加进去的依赖的。而你如果需要指定一些安装时可选的依赖包，只需要用 pdm add -G group_name 命令去添加依赖。

从使用体验来讲，分组功能是我选择 PDM 最重要的原因之一。

pdm install && update

基本用法也和其他管理工具相同。这两个命令也都支持 -G 命令用以安装、更新指定分组内指定的依赖。

pdm run

如果你没有开启 pdm --pep582 却又想让你的 Python 代码能正确地找到你安装的包，或是想要执行一个第三方包携带的可执行文件，那么你就得把 pdm run 加在你每一个在项目里执行的命令的前面。

除此之外，PDM 还允许你自己包装一些命令，就像 npm run 一样。

# pyproject.toml

[tool.pdm.scripts]
_.env_file = ".env" # 注意这一行配置的意思是解析 `.env` 文件的内容加进各命令执行时的环境变量
serve = "index-cli uvicorn main:app"
migrate = "python -m shoucang migrate main"

pdm export

Python-Poetry 最让人诟病的一点就是一开始没有 export 命令，后面妥协了却又只有 requirements.txt 格式的，搞得我自己写了一个 poetry2setup 来用。

PDM 则自带种种格式导出，随时可以一键跑路😀。

PyPi Mirror

对于中国用户来说，这个功能可以说是必不可缺的。PDM 作为一个中国人开发的工具自然也包含这个功能，而且使用起来相较于 Pipenv 和 Python-Poetry 更加方便。

pdm config pypi.url https://pypi.tuna.tsinghua.edu.cn/simple

Hooks

为了方便构建 docker 镜像，可以使用 pdm 的 hook 机制让你的项目 requirements.txt 自动跟随 pdm.lock 更新。

[tool.pdm.scripts]
post_lock = "pdm export --production -f requirements -o requirements.txt --without-hashes"

如果你使用了 pre-commit 还可以配置让所有人自动执行安装

[tool.pdm.scripts]
post_install = "pre-commit install"

ContextVars 详解

Tue, 11 May 2021 16:31:26 +0000

ContextVars 是 Python3.7 以及之后版本里的标准库。

应用场景

Context managers that have state should use Context Variables instead of threading.local() to prevent their state from bleeding to other code unexpectedly, when used in concurrent code.

从官方文档的说明来看，它是用于解决并发代码里的长生命周期变量的管理问题的。这里的“并发代码”就是指使用了 async/await 的协程代码。

那么，什么是“长生命周期变量”？如果你使用过 bottle/flask 当中的一个就能知道 request 这个变量能在框架处理请求的大部分过程中被调用，并且在不同的请求之间，它的值是互相隔离的。它虽然被创建在整个调用过程的开始，却不需要显式的层层传递给每个函数。它看起来像是一个全局变量，但却不是程序结束才被销毁、并且也不是全局共享的——它对于每个请求来说都是唯一无二的变量。

在传统的多线程编程里，使用 threading.local() 就可以做到这一点，但在 async/await 这种多协程编程里，往往一个线程内要跑许多个协程，使用 threading.local() 无法达到这个目的。但协程又号称微线程，对标的是用户级线程，那么自然也需要一种方式来隔离多个协程之间的长生命周期变量，于是 ContextVars 应运而生。

实现原理

ContextVars 是怎么做到协程间隔离变量的呢？

https://github.com/MagicStack/contextvars 是同一个作者为低版本 Python 写的兼容实现，可以看出来它只是继承了 Mapping 然后实现了 Copy 方法而已，唯一的隔离在 copy_context 里。

在它的相关 PEP 文档——PEP-567里提到，在 asyncio 几个关键函数里增加了 copy_context 方法，然后再调用 context.run 去执行回调函数。

简单粗暴但很有效的做法。

这与我们直接使用此标准库提供的接口 context.run 跑普通函数没有区别，asyncio 只不过是把需要程序员手动 copy_context 的行为放到源码里执行了。

与 asyncio 一起使用

import asyncio
import contextvars

client_addr_var = contextvars.ContextVar('client_addr')

def render_goodbye():
    # 从 client_addr_var 获取当前连接地址
    client_addr = client_addr_var.get()
    return f'Good bye, client @ {client_addr}\n'.encode()

async def handle_request(reader, writer):
    addr = writer.transport.get_extra_info('socket').getpeername()
    # 在设置完之后，就可以使用 client_addr_var.get() 获取设置的值
    token = client_addr_var.set(addr)

    try:
        while True:
            line = await reader.readline()
            print(line)
            if not line.strip():
                break
            writer.write(line)

        writer.write(render_goodbye())
        writer.close()
    finally:
        # 使用 token 重置值到上次 set 前
        client_addr_var.reset(token)

async def main():
    srv = await asyncio.start_server(
        handle_request, '127.0.0.1', 8081)

    async with srv:
        await srv.serve_forever()

asyncio.run(main())

pip 安装与脚本安装

Tue, 07 Jul 2020 07:57:58 +0000

很多著名的库，例如 poetry 虽然提供了 PyPi 包，但它们仍然推荐使用它们自身编写的安装脚本去安装。

这是为什么？

众所周知，使用 pip 命令默认是安装到系统的 python 环境里的。当你安装的包过多，总会遇到依赖冲突的事（如果没遇到，说明你很幸运）——一个库依赖于另一个库的 0.5 版本，而第三个库依赖于 1.2 版本，两个版本大相径庭完全无法兼容。就会导致你必须放弃一个。

而 poetry 等著名库的安装脚本会为你创建好虚拟环境，在虚拟环境中安装。看起来很美好，不过……对于新手而言，譬如我的几个朋友，他们对电脑没那么熟悉，如果你让他找 pip 安装的路径他们还算能勉强搞定。但这种对于他们来说像是黑魔法一样的脚本安装方式，卸载都是一件困难的事情。

其实这个问题的解决办法很简单，不再使用脚本安装。统统用 pipx 去安装。

pipx 是一个专门用于安装命令行工具的命令行工具。当然，折腾它的脚本安装方式也不是十分容易的事——如果你搞不明白 get-poetry.sh 的安装与卸载，那么肯定也对 pipx 的脚本安装与卸载迷迷糊糊的。

但这都不重要。直接使用系统的 pip 命令安装就好了。依赖冲突？除了 pipx 本身以外，其他命令行工具全部用 pipx 管理，这就解决了冲突问题。

pip install -U pipx

pipx 的原理十分简单易懂：在安装命令时，它自动创建一个虚拟环境，并把你需要安装的包安装进去，将包安装后产生的可执行文件暴露在环境变量里。它本身就是使用 Python 编写的，十分适合在在各种需要安装很多发布在 PyPi 的命令行工具的系统上使用。

而接下来这一步，会难倒很多不看程序输出、或者不看程序英文输出的人，尽管它已经在 pipx 安装之后被输出了。

在安装完 pipx 之后，你需要执行 pipx ensurepath 命令来确保 pipx 用以暴露可执行文件的文件夹被包含在环境变量里。注意：执行完这条命令后，你需要关闭控制台并重新启动一个新的，在原本那个控制台里，设置并不会生效。

接下来就可以愉快的使用 pipx 来管理你的命令行程序们了，以下是三个最常用的命令，分别是安装、卸载、升级和列举已安装的包和位置。

pipx install PACKAGE

pipx uninstall PACKAGE

pipx upgrade PACKAGE

pipx list

以下是我自己安装的命令行工具：

pipx install docker-compose
pipx install poetry
pipx install pipenv
pipx install certbot

poetry 使用指北

Fri, 10 Jan 2020 03:18:34 +0000

poetry 满足了我对包管理器的一切愿望，它的野心有点大，向着 Python 界的 npm 一路狂奔。

但这不是贬义词，它是一款比 pipenv 优秀的包管理器——当你适应它之后。

poetry init

就像 npm init 一样，poetry 也需要使用 init 命令创建 pyproject.toml 文件，当然你也可以手动。

这一命令并不会帮助你创建虚拟环境，它仅仅是创建一个 pyproject.toml 用来描述你的项目而已。

poetry env

此命令以及子命令用于处理虚拟环境相关的操作。

如果需要创建的虚拟环境与当前系统默认的 Python 版本不一致，pypoetry 会自动去寻找不同于当前 Python 环境的 Python 解释器位置，如果它找不到，那么就只能手动指定解析器的绝对路径。

在非 Windows 系统上，一般可以通过 which python、which python3.7 一类的命令寻找到自己指定的 Python 版本的位置。

在 Windows 系统中，可以通过环境变量来寻找 Python 的解释器位置。

poetry env use PYTHONPATH

使用 poetry env use PYTHONPATH 命令创建虚拟环境。

# in windows
poetry env use C:\Users\AberS\AppData\Local\Programs\Python\Python38\python.exe

poetry env list

poetry 比 pipenv 要强的是，可以使用 poetry env use PYTHONPATH 为一个项目创建多个不同的虚拟环境。

通过 poetry env list 可以查看当前项目所有的虚拟环境，增加 --full-path 可以看到虚拟环境的完整路径，一般在配置 VSCode、PyCharm 的时候需要使用。

poetry install & update

与 pipenv install 和 pipenv update 行为完全一致的愚蠢不同的是，poetry 的 install 和 update 真的做到了字面上的意思，install 就是安装所有的依赖，update 就是升级所有依赖，并且 update 真的可以指定一个包做到只更新它。

# 安装**所有的**依赖
# 如果没有虚拟环境，将会自动使用当前 Python 环境安装一个
poetry install
# 仅安装非 development 环境的依赖，一般部署时使用
poetry install --no-dev

poetry add & remove

与 npm 相同，poetry 增加/删除依赖使用 add/remove 命令。

为 add 命令增加 --dev 选项，可以把库标记为 development，当使用 poetry install --no-dev 时，不会安装它们。

poetry shell & run

与 pipenv 相同，poetry shell 可以在 shell 中激活当前虚拟环境；poetry run 可以直接在当前虚拟环境中运行命令。

poetry build & publish

poetry 是一个全面的包管理器，即可以管理别人，也可以管理自己。

以下是我第一个使用 poetry 发布 pypi 包的项目——websocks 中的配置。

[tool.poetry]
name = "websocks"
version = "0.1.9"
description = "A websocket-based socks5 proxy."
readme = "README.md"
authors = ["abersheeran <me@abersheeran.com>"]
license = "MIT"

homepage = "https://github.com/abersheeran/websocks"
repository = "https://github.com/abersheeran/websocks"
documentation = "https://github.com/abersheeran/websocks/wiki"
classifiers=[
    "Programming Language :: Python :: 3.6",
    "Programming Language :: Python :: 3.7",
    "Programming Language :: Python :: Implementation :: CPython",
    "Programming Language :: Python :: Implementation :: PyPy",
]

packages = [
    { include = "websocks" },
]

[tool.poetry.scripts]
websocks =  'websocks.commands:main'

写过 setup.py 的人都会明白以上配置的含义，在此不做赘述。它的意义在于，我们再也不用写该死的 setup.py 了，一个 pyproject.toml 文件即可。

使用 poetry build 可以把项目打包成一个 .whl 文件用于安装。

然后可以使用 poetry publish 发布到 pypi 上，如果你不想执行两条命令，那么可以把 poetry build; poetry publish 合并成一条 poetry publish --build，这将做出同样的行为——先打包，后发布。

poetry config

poetry config 允许配置一些 poetry 的默认行为。

譬如：poetry config virtualenvs.in-project true 可以设置虚拟环境默认安装到项目的 .venv 目录里。

poetry config virtualenvs.create false --local 在部署时先使用这个命令可以使所有的包安装到系统中，而不是虚拟环境里。

使用 PyPi 镜像

由于网络原因，部分地区使用默认的 PyPi 源可能效果不佳。通过在 pyproject.toml 中配置源可以使 poetry 从指定的 PyPi 镜像中拉取代码。注意 default = true 是必须的，否则 poetry 仍然会从默认源拉取哈希值。

[[tool.poetry.source]]
name = "tsinghua"
default = true
url = "https://pypi.tuna.tsinghua.edu.cn/simple"

题外话

我在把 websocks 从 pipenv + setup.py 转移到 poetry 之后，发生了一个问题，docker 的自动构建失败了。

由于 pyproject.toml 是 PEP 标准的一部分，可以直接使用 pip3 install . 去安装整个包。但这个过程中，会自动下载 poetry，既会增加最终镜像的大小，还需要安装一些用来编译 poetry 的依赖包的依赖。就在这里，我使用的 python:3.7-alpine 不负所托的失败了，但我不想增加最终镜像的大小。

于是一番查找之下，我使用了 dephell 把 pyproject.toml 转译成纯净的 setup.py，再使用 docker 的分段构建，只把转译好的 setup.py 保留下来，这么一来，镜像大小比原来还小几百个字节，虽然几百个字节对于现代计算机来说没什么用。😀😀如果有老旧项目需要从各种环境管理、包管理的魔爪下逃脱，建议试试 dephell。

好看易用的命令行

Sun, 03 Nov 2019 06:10:47 +0000

在之前的一篇文章输出彩色命令行里，我介绍了 Colorama 的基本使用方法。但作为一个命令行程序，除了好看的五颜六色的输出，还需要解析命令行参数。

一个简单好用的库——click，不仅集成了 Colorama，还提供了更简单的命令行解析。

Command（命令）

使用click创建一个命令十分简单：

import click


@click.command(help="just say hi")
def sayhi():
    print('hi')


if __name__ == "__main__":
    sayhi()

尝试执行这个文件，你将能看一个平凡的hi。

那么接下来，尝试让它接受一些参数、或者选项。

Argument（参数）

import click


@click.command(help="just say hi")
@click.argument("name")
def sayhi(name):
    print(f'hi {name}')


if __name__ == "__main__":
    sayhi()

再尝试直接运行这个文件，你能看到如下报错

⚡ AberS@SHEERAN  ~\Desktop
❯ python .\sayhi.py
Usage: sayhi.py [OPTIONS] NAME
Try "sayhi.py --help" for help.

Error: Missing argument "NAME".

或许你在想，是不是因为调用sayhi的时候缺少了参数name，但并不是。@click.command会将函数签名抹去，当你直接调用sayhi的时候，实际直接调用的并不是sayhi。

试试执行python sayhi.py aber这个命令，你将能看到hi aber。

多值参数

接下来尝试让这个小脚本同时向更多人打招呼：

import click


@click.command(help="just say hi")
@click.argument("name", nargs=-1)
def sayhi(name):
    print('hi', ", ".join(name))


if __name__ == "__main__":
    sayhi()

nargs 选项允许 argument 接受更多的内容，当它的值为正整数时，接受指定数目的内容；当它的值为-1时，它将接受所有的参数。所以一个command下，只能有一个argument的nargs被指定为-1。

❯ python .\sayhi.py aber alice bob sherry
hi aber, alice, bob, sherry

Option（选项）

选项分长选项(--option)和短选项(-o)，一般来说是相对应的。

import click


@click.command(help="just say hi")
@click.option("-k", "--keyword", required=True)
@click.argument("name", nargs=-1)
def sayhi(name, keyword):
    print('hi', keyword, ", ".join(name))


if __name__ == "__main__":
    sayhi()

必须选项

执行命令时不带选项，则默认为None。但如果给option加上required=True，则必须携带此选项。

❯ python .\sayhi.py aber
Usage: sayhi.py [OPTIONS] [NAME]...
Try "sayhi.py --help" for help.

Error: Missing option "-k" / "--keyword".

规避关键词冲突

有些时候，选项名可能会与Python的关键词冲突，如下：

import click


@click.command(help="just say hi")
@click.option("-k", "--keyword", required=True)
@click.option('--from', '-f', 'from_')
@click.argument("name", nargs=-1)
def sayhi(from_, name, keyword):
    print(from_, ': hi', keyword, ", ".join(name))


if __name__ == "__main__":
    sayhi()

试试执行命令python sayhi.py aber -k ", what are you doing now?"：

❯ python .\sayhi.py aber -k ", what are you doing now?"
None : hi , what are you doing now? aber

如果稍微敏锐一点，你可能会注意到，函数参数值与位置无关，这是因为click是通过关键词参数传递参数值的。

选项默认值

选项可以被设置默认值，并且在--help命令下显示出来。

import click


@click.command(help="just say hi")
@click.option("-k", "--keyword", required=True)
@click.option('--from', '-f', 'from_', default="Aber", show_default=True)
@click.argument("name", nargs=-1)
def sayhi(from_, name, keyword):
    print(from_, ': hi', keyword, ", ".join(name))


if __name__ == "__main__":
    sayhi()

然后看看执行结果：

❯ python .\sayhi.py Sherry -k ", what are you doing now?"
Aber : hi , what are you doing now? Sherry

❯ python .\sayhi.py --help
Usage: sayhi.py [OPTIONS] [NAME]...

  just say hi

Options:
  -k, --keyword TEXT  [required]
  -f, --from TEXT     [default: Aber]
  --help              Show this message and exit.

多值选项

同样的，option也提供了nargs参数用以接收多个值，与参数类似。

多选项值

设置 multiple=True 即可允许接受 -m bob -m sherry 这类选项。

布尔类型选项

click推荐给布尔类型的选项一对值，在修改默认值时会比较方便。

import click


@click.command(help="just say hi")
@click.option("-k", "--keyword", required=True)
@click.option('--from', '-f', 'from_', default="Aber", show_default=True)
@click.option('--debug/--no-debug', default=False)
@click.argument("name", nargs=-1)
def sayhi(from_, name, keyword, debug):
    print(debug, from_, ': hi', keyword, ", ".join(name))


if __name__ == "__main__":
    sayhi()

执行结果如下：

❯ python .\sayhi.py Sherry -k ", what are you doing now?"
False Aber : hi , what are you doing now? Sherry

❯ python .\sayhi.py Sherry -k ", what are you doing now?" --debug
True Aber : hi , what are you doing now? Sherry

❯ python .\sayhi.py Sherry -k ", what are you doing now?" --no-debug
False Aber : hi , what are you doing now? Sherry

但有些时候，或许只是需要开启或者不开启，而不是需要在开启/关闭状态间显式的指定。

将@click.option('--debug/--no-debug', default=False)修改为@click.option('--debug', is_flag=True)。它的执行效果与上面的相同，但不能接受--no-debug的选项。

组合命令

更多的时候，我们需要构建的命令行程序由多个子命令组成。以pipenv为例，pipenv本身是一个命令，同时它也拥有众多子命令。

click提供了这样的能力，使用click.group，这将允许把一些命令挂载主命令下。

把原来的click.command替换为click.group，然后加入子命令。

import click


@click.group(help="just say hi")
@click.option("-k", "--keyword", required=True)
@click.option('--from', '-f', 'from_', default="Aber", show_default=True)
@click.option('--debug', is_flag=True)
@click.argument("name", nargs=-1)
def sayhi(from_, name, keyword, debug):
    print(debug, from_, ': hi', keyword, ", ".join(name))


@sayhi.command(help="just say bye")
def saybye():
    print("bye")


if __name__ == "__main__":
    sayhi()

尝试一下 --help 能看到子命令已经成功加入了。

❯ python .\sayhi.py --help
Usage: sayhi.py [OPTIONS] [NAME]... COMMAND [ARGS]...

  just say hi

Options:
  -k, --keyword TEXT  [required]
  -f, --from TEXT     [default: Aber]
  --debug
  --help              Show this message and exit.

Commands:
  saybye  just say bye

其他功能

多彩输出

click的secho函数提供了一个比较好用的输出功能。

click.secho("hello world", fg="green")

fg可用的选项有：

black (可能是灰色)
red
green
yellow (可能是橘色)
blue
magenta
cyan
white (可能是亮灰色)
bright_black
bright_red
bright_green
bright_yellow
bright_blue
bright_magenta
bright_cyan
bright_white
reset (重置颜色)

如果不想在最后输出换行符可以设置nl=False：

click.secho("hello world", fg="red", nl=False)

Prompts（输入）

click.prompts在默认情况下支持任何unicode输入，但你也可以指定输入类型

value = click.prompt('Please enter a valid integer', type=int)

在提供了默认值时，类型会被自动确定

value = click.prompt('Please enter a number', default=42.0)

更多的功能例如进度条、打开文件、执行文件等，可看click/utils。

Aligi

Sun, 11 Aug 2019 07:14:13 +0000

无服务函数也许是近来较为热门的一个东西。由于我没得信用卡，无奈只好在阿里云上小试一番。

但我惊奇的发现，如果使用flask等支持WSGI的Web框架去写一个无服务函数，是没办法直接用阿里云的API网关去调用函数的。因为网关为了通用性，它不可能一个个协议去做适配。

那么我为了方便开发与使用，创造了Aliyun Gateway Interface(aligi)。

如何使用

按例，pip install aligi安装一下。

WSGI

对于Flask、Django等支持WSGI的项目，使用起来很简单。

from aligi.wsgi import WSGI

# 阿里云无服务函数的入口
handler = WSGI(APP)

其中APP使用自己的项目的WSGI Application代替即可。

一般来说，flask中的Application就是Flask(__name__)的实例；django的Application则在项目的wsgi.py文件中。

不需要对原始代码做任何修改！你就可以将项目放上无服务函数，配合 API 网关，上线项目了！

Python使用JWT

Wed, 07 Aug 2019 13:18:50 +0000

最近在用阿里云的函数计算服务，需要使用JWK(Json Web Key)来生成JWT(Json Web Token)，一时之间竟没有找到一个优雅的、提供JWK生成JWT的库，差点绝望的使用了阿里云给的Java样例。然后惊喜的发现PyJWT其实是支持JWK的，但是文档上并没有写。

此篇做一个系统的梳理，算是对官方文档的补充。

安装

如果你不需要使用类似于RSA的加密算法，那么正常的pipenv install pyjwt即可，否则应该使用pipenv install pyjwt[crypto]去安装（这会安装cryptography）。

一般使用

对称加密

常规使用JWT一般会使用对称加密进行签名，一是加解密速度相对快，二是密钥容易配置——随便一个字符串就行了。

以下为PyJWT官方文档例子：

>>> import jwt

>>> encoded_jwt = jwt.encode({'some': 'payload'}, 'SECRET', algorithm='HS256')
>>> encoded_jwt
'eyJhbGciOiJIU...'
>>> jwt.decode(encoded_jwt, 'SECRET', algorithms=['HS256'])
{'some': 'payload'}

其中SECRET就是需要保管的密钥，algorithm则指定了签名方法，algorithms指定验证签名时尝试使用的方法列表。

encode与decode的第一个参数就是需要进行签名的数据。

非对称加密

事实上常规使用非对称加密进行签名也很简单，自己生成一对密钥。

下面依旧是官方文档的例子：

>>> import jwt
>>> private_key = b'-----BEGIN PRIVATE KEY-----\nMIGEAgEAMBAGByqGSM49AgEGBS...'
>>> public_key = b'-----BEGIN PUBLIC KEY-----\nMHYwEAYHKoZIzj0CAQYFK4EEAC...'
>>> encoded = jwt.encode({'some': 'payload'}, private_key, algorithm='RS256')
'eyJhbGciOiJIU...'
>>> decoded = jwt.decode(encoded, public_key, algorithms='RS256')
{'some': 'payload'}

除了注意验证签名时用公钥，签名时用私钥。写起来与对称加密签名没什么不同。

JWK使用

JWK是由RFC7517定义的格式。它一般是一个JSON对象。可以在 https://mkjwk.org/ 网站生成一对 JWK 对象。

from jwt.algorithms import RSAAlgorithm

RSAPublicKey = RSAAlgorithm.from_jwk(JWK-Public)
RSAPrivateKey = RSAAlgorithm.from_jwk(JWK-Private)

首先，分别使用JWK的公钥(JWK-Public)与私钥(JWK-Private)生成需要使用的公钥与私钥对象。注意，这里两者必须都是正确的JSON格式的字符串。

接下来的使用就如同常规的非对称加密方法一样了：

token = jwt.encode(data, key=RSAPrivateKey, algorithm='RS256')
data = jwt.decode(token, key=RSAPublicKey, algorithms="RS256")

在这里不得不吐槽一下，关于给PyJWT补充JWK的文档其实早有讨论，但是不知道为什么就不了了之了。快两年了吧，文档里还是没有介绍如何使用JWK。

Django app配置子域名

Sun, 24 Feb 2019 00:00:00 +0000

最近由于PM的需求，又去研究了Django一个app对应一个子域名的用法。寻找资料的过程中发现没有较好的中文教程，遂有此篇。

安装Django-Hosts

按照惯例，首先需要pipenv install django-hosts(如果你没有pipenv, pip也是一样的)。

把'django_hosts'加入项目设置中的INSTALLED_APPS

把'django_hosts.middleware.HostsRequestMiddleware' 加到项目设置中的MIDDLEWARE的第一行。

把'django_hosts.middleware.HostsResponseMiddleware' 加到项目设置中的MIDDLEWARE的最后一行。

完成之后你的MIDDLEWARE配置看起来就像这样

MIDDLEWARE = [
    'django_hosts.middleware.HostsRequestMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'django_hosts.middleware.HostsResponseMiddleware',
]

在项目settings.py的同目录下创建一个hosts.py。
在settings.py里增加三个变量
1. ROOT_HOSTCONF = 'mysite.hosts'
  
  它指向你上一步创建的hosts.py
2. DEFAULT_HOST
  
  当没有匹配到对应的子域名时，会默认使用这个子域名。一般来说，你可以设置为'www'
3. PARENT_HOST
  
  要附加到反向域的父域名。(也许你现在搞不懂它有什么用，往下看)

编写规则

在hosts.py文件里写入如下的代码

from django.conf import settings
from django_hosts import patterns, host

host_patterns = patterns(
    '',
    host(r'www', settings.ROOT_URLCONF, name='www'),
    host(r'api', 'api.urls', name='api'),
)

然后在ALLOWED_HOSTS里加入它们，例如 ['www.abersheeran.com', 'api.abersheeran.com']。要注意，像['*.abersheeran.com']这样的通配符是没用的。

当一个请求到达时，会最先被'django_hosts.middleware.HostsRequestMiddleware'获取，然后根据hosts里的配置匹配到对应的根urls里。

至于各个app里的urls都直接按照Django正常的写法就好。

模板编写以及其他

Django的url最让人舒服的一点就是可以通过唯一的名称空间 + URL名称映射到具体的url，使得产品经理要求更改url路径时，不需要那么麻烦。

在使用Django-Hosts之后，这种映射依旧存在（hosts.py中每个host都要有name），但需要修改一下模板的书写规则

{% load hosts %}
<a href="{% host_url 'homepage' host 'www' %}">Home</a> |

或者，如果你需要在Python代码里获取到对应的url, 那么可以这么写

from django.shortcuts import render
from django_hosts.resolvers import reverse

def homepage(request):
    homepage_url = reverse('homepage', host='www')
    return render(request, 'homepage.html', {'homepage_url': homepage_url})

这些反向映射的url，都会变成 host + PARENT_HOST 的域名形式。例如{% host_url 'homepage' host 'www' %}这个会被映射到www.PARENT_HOST。如果你没有设置PARENT_HOST，它将被映射到类似于http://www/home之类的url上。

还有更多的用法，都在本文第一个链接所给的官方文档中。没有多少英文，更多的是代码，可以尝试自己读一读。

一个样例

对于有很多个子域名站点来说，一个个进行手动注册管理，就很麻烦了。于是我对稍微利用了一下Django的规则来自动注册。

首先修改hosts.py如下。

from django.conf import settings
from django_hosts import patterns, host

host_patterns = patterns(
    '',
    *[host(subdomain, subdomain+'.urls', name=subdomain) for subdomain in settings.SUBDOMAINS]
)

再修改settings.py中的部分配置

ROOT_DOMAIN = '.abersheeran.com'

# Django-Host settings
# https://django-hosts.readthedocs.io/en/latest/index.html

ROOT_HOSTCONF = 'mysite.hosts'

DEFAULT_HOST = 'www'

ROOT_URLCONF = 'www.urls'

# 子域名对应的app名
# 例如 api.abersheeran.com 对应的app为 api
SUBDOMAINS = [
    'www',
    'api',
]

ALLOWED_HOSTS = [domain + '.localhost' if DEBUG else ROOT_DOMAIN for domain in SUBDOMAINS]

# Application definition

INSTALLED_APPS = SUBDOMAINS + [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django_hosts',  # 多域名
]

每个子域名都对应自己的同名app，譬如www这个app对应的就是www.abersheeran.com。

当开启DEBUG时，自动将各个子域名挂到localhost上，譬如访问api.localhost就可以进行api这个app 的测试。关闭DEBUG时，默认是部署到线上环境了，就自动将测试使用的localhost替换成真正使用的域名。

题外话

如何进行本地测试

例如访问api.example.com。你只需要修改本机的hosts文件，把api.example.com映射到127.0.0.1即可。对于不同的系统，hosts文件存在的路径不同，Linux大多在/etc/hosts，Windows10则是在C:\Windows\System32\drivers\etc\hosts。当然，你也可以为了这么点小事下个第三方工具来用，不过它们也都是修改hosts文件来做到这一点，只是封装了一下界面而已。

最佳的方案还是使用诸如api.localhost的localhost的子域名，因为它们默认就是访问本地的服务器(至少经我实验， Windows10上如此)

输出彩色命令行

Sat, 15 Sep 2018 00:00:00 +0000

Windows7之后的Windows系统自带的CMD或者Powershell，就不再支持ANSI代码来控制颜色了。那么我们如果想要改变Windows的命令行颜色，只好通过Windows给的句柄来控制颜色。

import sys
import ctypes

if sys.platform.startswith('win'):
    stdout = ctypes.windll.kernel32.GetStdHandle(-11)
    def printf(value, color=None, **kwargs):
        if color is None:
            print(value, flush=True, **kwargs)
        elif color == "green":
            ctypes.windll.kernel32.SetConsoleTextAttribute(stdout, 0x0a)
            print(value, flush=True, **kwargs)
        elif color == "yellow":
            ctypes.windll.kernel32.SetConsoleTextAttribute(stdout, 0x0e)
            print(value, flush=True, **kwargs)
        elif color == "red":
            ctypes.windll.kernel32.SetConsoleTextAttribute(stdout, 0x0c)
            print(value, flush=True, **kwargs)
        else:
            raise AttributeError("The color is unexpected!")
        ctypes.windll.kernel32.SetConsoleTextAttribute(stdout, 0x0f)

首先ctypes.windll.kernel32.GetStdHandle(-11)是获取stdout的句柄。然后通过ctypes.windll.kernel32.SetConsoleTextAttribute(句柄，颜色代码)控制文字和背景颜色。

为了代码更好看，我们或许需要更好的封装这些函数。但这些都没必要，Python的哲学就是别造重复的轮子。

Colorama

只需要pip install colorama，就可以使用封装好的跨平台命令行颜色控制库。

可用格式参数如下

Fore: BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE, RESET.
Back: BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE, RESET.
Style: DIM, NORMAL, BRIGHT, RESET_ALL

在Github上给的样例如下

from colorama import Fore, Back, Style
print(Fore.RED + 'some red text')
print(Back.GREEN + 'and with a green background')
print(Style.DIM + 'and in dim text')
print(Style.RESET_ALL)
print('back to normal now')

可以在代码前加以下两行让Python的print支持ASNI代码来控制任意平台的输出颜色

from colorama import init
init()

需要自动回复字体颜色还可以这样

from colorama import init
init(autoreset=True)

就无须手动恢复字体颜色了。

Supervisor

Thu, 28 Jun 2018 00:00:00 +0000

最近我一个开发怎么就干上了运维的活，此篇以作记录。

下载之后修改/etc/supervisord.conf其中取消后台Web端口的注释

[inet_http_server]         ; inet (TCP) server disabled by default
port=127.0.0.1:9001        ; (ip_address:port specifier, *:port for all iface)
username=User              ; (default is no username (open server))
password=Pass              ; (default is no password (open server))

这样可以在对应的web界面可视化的管理和查看进程。
当然也可以取消[unix_http_server]的注释，这样只能使用Nginx一类的反向代理服务器代理它之后才能直接看，好处是，不用多占一个端口。

然后翻到最下面，查看以下语句是否被注释，如果被注释了，就取消注释

[include]
files = supervisord.d/*.ini

这个就是把对应目录下的 ini 配置文件读取出来作为配置，便于管理。

编写被管理进程配置

在上述配置文件目录下建立任意的.ini文件，写入配置。

一般来说，以下的配置就足够了(此处以uwsgi作为样例)，更多配置请查看官方文档

[program:uwsgi]
command=uwsgi --emperor uwsgi.d
directory=/website
user=uwsgi
stdout_logfile=/website/uwsgi.d/emperor.log
redirect_stderr=true
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true

这里有一个坑，redirect_stderr=true如果没有，那么某些程序的日志就没法正常显示。目下看来，至少Python自带的logging模块和uwsgi的日志都会因为没有这个选项而不在我们指定的日志文件中出现。因为他们的日志都是输出到stderr里的。

Python的Print无法显示到日志
这可能是因为缓冲区的问题，只需要运行时加-u参数即可，例如: python -u run.py

运行

使用supervisord -c /etc/supervisord.conf启动后台进程。

一些管理命令如下

$ supervisorctl status
$ supervisorctl stop uwsgi
$ supervisorctl start uwsgi
$ supervisorctl restart uwsgi
$ supervisorctl reread
$ supervisorctl update

Pyinstaller打包代码

Mon, 14 May 2018 00:00:00 +0000

一般来说Python打包成系统可执行文件，有两个库，但支持更新版本(3.6+)的Python的就是Pyinstaller了，有趣的是Pyinstaller在windows7上运行的十分完美，到windows10上就有一些warning，它是由于win10的feature导致的，这个warning并不影响我们的打包。

在win10上面打包虽然有warning，但是打包出来的exe放到别的电脑上跑就没有问题。在win7打包出来的，放到别的win7上就找不到dll，我差点因为这个而挂科。

安装Pyinstaller

首先pip install pyinstaller安装这个第三方库，先尝试使用一下，如果出现提示要安装pywin32之类的，就去 https://github.com/mhammond/pywin32/releases 找到适合自己Python和系统版本的Pywin32，然后下载安装。

注意：
如果你的Python安装路径里带有空格，需要修改对应目录下的某个文件的注释。但我这里不写出来，因为如果你还把Python装在带有空格的目录下，就算这个问题能够解决，以后还会有其他的问题。
趁早把安装路径改了吧。

打包

直接将命令行切换到写好的运行文件目录下，运行命令pyinstaller -F 文件名 会帮你处理好依赖关系和文件，打包成一个exe文件在目录下的dist文件夹里。你可以去掉-F，这样子就会打包成一个文件夹的形式，同样会有一个入口exe文件在文件夹里。

如果你觉得默认图标太丑(反正我觉得太丑)，可以在打包的时候加上-i 图标文件路径来增加图标，图标应该像你所使用的其他任何软件一样 —— 最好使用.ico文件。

黑框这种东西，外行人看起来总是觉得很low，想要打包之后的exe运行没有黑框，只要在打包的时候加上-w即可。

更多的选项可以查看 Pyinstaller的文档

打包多进程

当你尝试直接打包一个使用了multproecssing模块的多进程Python程序时，它肯定不会正常的按照你的意志进行打包。

pyinstaller的开发者对此专门写了一篇Wiki。当你使用最新版的Pyinstaller的时候，只需要如下，加一行代码即可。

if __name__ == "__main__":
    multiprocessing.freeze_support()

当你的Pyinstaller版本低于3.3，就比较复杂了，你需要加上这个代码

import os
import sys

# Module multiprocessing is organized differently in Python 3.4+
try:
    # Python 3.4+
    if sys.platform.startswith('win'):
        import multiprocessing.popen_spawn_win32 as forking
    else:
        import multiprocessing.popen_fork as forking
except ImportError:
    import multiprocessing.forking as forking

if sys.platform.startswith('win'):
    # First define a modified version of Popen.
    class _Popen(forking.Popen):
        def __init__(self, *args, **kw):
            if hasattr(sys, 'frozen'):
                # We have to set original _MEIPASS2 value from sys._MEIPASS
                # to get --onefile mode working.
                os.putenv('_MEIPASS2', sys._MEIPASS)
            try:
                super(_Popen, self).__init__(*args, **kw)
            finally:
                if hasattr(sys, 'frozen'):
                    # On some platforms (e.g. AIX) 'os.unsetenv()' is not
                    # available. In those cases we cannot delete the variable
                    # but only set it to the empty string. The bootloader
                    # can handle this case.
                    if hasattr(os, 'unsetenv'):
                        os.unsetenv('_MEIPASS2')
                    else:
                        os.putenv('_MEIPASS2', '')

    # Second override 'Popen' class with our modified version.
    forking.Popen = _Popen

当然，现在pip安装的，都是3.3版本以上的。

打包额外文件

当需要打包的时候把一些其他文件复制到dist中。可以增加额外的命令参数：--add-data="文件路径;复制后的文件路径"

例如复制根目录下的snake.ico文件到打包后的文件夹的根目录下--add-data="snake.ico;."，在类Unix系统(MacOS,Linux)中使用:替换;。

监听文件事件

Wed, 21 Feb 2018 00:00:00 +0000

最近在完善自己的轮子的时候，遇到了一个问题，需要监听文件变化，查了查资料，写下此篇以作记录。

Watchdog

由于没找到能直接用的标准库，所以选择用了这个简单易用的第三方库。

调用它很简单，官方给的例子如下

import sys
import time
import logging
from watchdog.observers import Observer
from watchdog.events import LoggingEventHandler

if __name__ == "__main__":
    logging.basicConfig(level=logging.INFO,
                        format='%(asctime)s - %(message)s',
                        datefmt='%Y-%m-%d %H:%M:%S')
    path = sys.argv[1] if len(sys.argv) > 1 else '.'
    event_handler = LoggingEventHandler()
    observer = Observer()
    observer.schedule(event_handler, path, recursive=True)
    observer.start()
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()

忽略掉其他细枝末节，关键在observer.schedule(event_handler, path, recursive=True)这一行，它的含义是

在path这个路径下触发更改事件时，将事件传递给event_handler进行处理。

那么我们来自定义个event_handler。首先这个类需要从FileSystemEventHandler这个事件处理基类继承，并重写事件处理方法。

事件处理方法如下：

self.dispatch(event)
接收到一个事件后，通过该方法来决定该event由下面哪个方法处理(一般情况下不予复写该方法)
self.on_any_event(event)
任何事件发生都会首先执行该方法，该方法默认为空，dispatch()方法会先执行该方法，然后再把event分派给其他方法处理
self.on_moved(event)
处理DirMovedEvent和FileMovedEvent事件，子类需重写该方法
self.on_created(event)
处理DirCreatedEvent和FileCreatedEvent事件，子类需重写该方法
self.on_deleted(event)
处理DirDeletedEvent和FileDeletedEvent事件，子类需重写该方法
self.on_modified(event)
处理DirModifiedEvent和FileModifiedEvent事件，子类需重写该方法

建立如下的子类

from watchdog.events import FileSystemEventHandler

class MonitorFileEventHandler(FileSystemEventHandler):

    def on_modified(self, event):
        file = os.path.basename(event.src_path)
        if file.split(".")[-1] == "html":
            logging.info("Update article {}".format(file.replace(".html", "")))
            update_blog(file.replace(".html", ""))

    def on_deleted(self, event):
        file = os.path.basename(event.src_path)
        if file.split(".")[-1] == "html":
            logging.info("Delete article {}".format(file.replace(".html", "")))
            delete_blog(file.replace(".html", ""))

这个类只对更改和删除做出反应。你当然可以自己复写如上方法来做自己想做的事情。

event有如下的属性：

event.is_directory
该事件是否由一个目录触发
event.src_path
触发该事件的文件或目录路径
event.event_type
事件类型，为moved、deleted、created或modified的其中之一
event.key
返回元组(event_type, src_path, is_directory)

你可以在复写的方法里使用它们来做到一些有趣的事情。

然后我又编写了一个类来调用这个事件类

from watchdog.observers import Observer

class MonitorFile:
    def __init__(self, path):
        self.observer=Observer()
        self.observer.schedule(MonitorFileEventHandler(), path, recursive=True)
        self.observer.start()

    def __del__(self):
        self.observer.stop()
        self.observer.join()

接下来只需要实例化一下这个类，然后保持自身不被kill就OK了。

类似于这样

main = MonitorFile("D:/")
try:
    while True:
        time.sleep(1)
except KeyboardInterrupt:
    pass

Django定时任务

Sat, 14 Oct 2017 00:00:00 +0000

定时任务无论是个人开发还是企业业务都是需要的。但个人开发的时候使用celery，未免有点杀鸡用牛刀的感觉。Celery性能不错，但配置起来并没有那么简单。非密集型的定时任务，我们完全可以使用django-background-tasks来替代Celery。

How to use

按例，pip install django-background-tasks来安装。

然后加入INSTALLED_APPS：

INSTALLED_APPS = (
    # ...
    'background_task',
    # ...
)

创建对应的数据库

python manage.py makemigrations background_task
python manage.py migrate

接下来就可以使用了，例如我有一个函数需要在被调用之后60秒才运行

from background_task import background

@background(schedule=60)
def task(user_id):
    do.somethings

这样定义task，在我们使用的时候，直接调用它就行了。调用这个函数，不会被马上执行，也不会阻塞原本所在的位置的程序执行，并且会被加入background_task对应的数据库里，我们可以在Django后台看到任务完成情况，并且进行管理。

最后，我们需要另开一个进程来处理这些定时任务

python manage.py process_tasks

如果想后台运行此进程，nohup python manage.py process_tasks > tasks.log & echo $! > tasks.pid &即可。运行的错误日志会被保存到tasks.log中，进程号会被存在tasks.pid中。

如果需要函数被调用之后，每隔一段时间就运行一次，只需要在调用时加上一个关键字参数repeat即可
```
# some statements
task(2, repeat=60*60*6)
```
例如此处，函数被调用之后，在60s之后运行，然后每隔60*60*6秒就会运行一次。

Extend

Django-background-tasks这个库是作为Django的一个app而存在的，所以Django的ORM对它依旧可以使用。

只需要导入对应的model-class就可以控制、访问任务完成的情况。

from background_task.models import Task

只执行一次定时任务

有些时候，我们只期望一个函数每隔一段时间运行一次。并且不期望这个函数任务被重复调用塞进任务数据库。那么可以通过查询任务数据库来做到这一点

可以看到DBT这个库关于任务的一部分定义如下，

@python_2_unicode_compatible
class Task(models.Model):
    # the "name" of the task/function to be run
    task_name = models.CharField(max_length=255, db_index=True)
    # the json encoded parameters to pass to the task
    task_params = models.TextField()
    # a sha1 hash of the name and params, to lookup already scheduled tasks
    task_hash = models.CharField(max_length=40, db_index=True)

    verbose_name = models.CharField(max_length=255, null=True, blank=True)

    ...

而每一个任务的task_name的值都是由该函数所在的App名.文件名.函数名组成，三者之间由.连接。

那么只需要通过Django自带的ORM进行查询Task，例如：

from background_task import background
from background_task.models import Task

@background(schedule=60)
def task(user_id):
    do.somethings


def index(request):
    if Task.objects.filter(task_name = "Clrawer.views.task").exists():
        pass
    else:
        task(2, repeat=60*60*6)

就可以在index这个视图函数被调用的时候，通过查询任务是否已经被加进了任务队列，来选择是否调用task函数。