标签归档：python

谨慎的乐观的看 Modular 提出的 Mojo 语言

有了 faster-cpython 的前车之鉴，对 Mojo 谨慎的乐观。

宣称将成为 Python 的超集是 Mojo 相比 Codon 等项目最吸引人的一点。Codon类项目虽然宣称是Python的编译器，但实际上砍掉了 Python 所有的动态特性，几乎所有的 Python 库都无法正常使用。对我而言，如果用不了 Python 生态，那这和一个全新的语言又有什么区别。

如果 Mojo 真成为Python的超集，单就比 CPython 性能高出一大截的 Python 编译器就足够吸引人。但细看下来，“成为 Python 超集”可能只是一个美好的愿望，达成的可能性非常小。现在 Mojo 的完成度还非常低，除了支持 Python 风格的语法外，Python还差很远（连 Class 都不支持）。现在版本的 Mojo 支持导入 Python 模块，但导入的 Python 模块是以 Python 对象的方式运行。换句话说就是塞了个 CPython 解释器到 Mojo 里用来执行 Python 代码（是不是立马不高大上了）。

除去 Mojo 吹牛的部分（比如那个比 Python 快 3500 倍），对 Mojo 还是有所期待。Mojo 的创始人有着牛逼哄哄的履历（LLVM & Swift 的作者）。虽然不能完全兼容 Python ，但承诺后期会提供相关的迁移工具。如果 Mojo 的性能和开发体验确实不错，Python库的迁移成本不高，还是会有不少人会自发的将 Python 生态迁移到 Mojo 到。

注：

使用Python做嵌入式开发

出于性能的考虑，传统的嵌入式开发都以C、C++为主。如今嵌入式设备的性能早已今非昔比，开发工具的选择方面也有了更大的自由度。对于非性能敏感的业务，Go、Python等开发语言引入的开发速度提升还是非常诱人。Python有着丰富的开发资源，在系统资源足够的情况下，Python在嵌入式环境下有着不错的开发体验。

性能

同Python高效的开发速度相对应的是Python的运行速度非常的慢，即使在脚本语言里Python也是最慢的一档。如果你的程序需要高性能，Python显然是不合适的。即使不需要高性能，也需要特别注意以保证用户体验。

使用的库尽量精简。在PC下Python的启动速度不会有明显的感觉，但在嵌入式设备下，用到的库多了后，第一个明显的感觉就是启动时间变长。如果用到的库多，启动时间甚至会超过10秒。嵌入式环境下引入一个新库需要更为谨慎，平衡好开发体验及性能影响。

程序打包（应用分发）

Python在跨平台方面做的非常优秀，大多情况下可以不需要嵌入式设备，直接本地开发调试。但程序发布的时候还需要针对应用平台就行打包。

pex会把所有的依赖和你自己的代码打包成一个.pex为后缀的可执行文件。在运行环境下直接执行该文件即可。由于开发环境的构架和运行环境的架构不一致，可以通过Docker容器就行程序的pex打包。

代码保护

对于商业项目，必要的代码保护还是有一定的必要。代码的保护可以选择下面几种方式。

  1. 编译成pyc
    • 使用命令 `python3 -m compileall -b ./;find ./ -name “*.py” -delete` 将代码编译成pyc，并删除py文件。
    • 该做法可以提供最低限度的代码保护。pyc还是可以较容易的反编译成py文件。
  2. 使用代码加密（混淆）工具对源代码进行加密。
    • 开源的代码加密工具都缺乏维护，很久未更新。如果有代码加密需求，建议使用商业工具。pyarmor
  3. 使用 Cython 、Nuitka 等工具将代码编译成二进制文件。
    • 相比 Cython，Nuitka的使用要简单很多，建议优先使用Nuitka。需要注意的是使用 Nuitka 后内存占用率会比直接用Python解释器高大概 1/3 。
    • Nuitka的编译也可在Docker容器中进行。

Python内存泄漏原因及问题排查

Python 会自动回收内存，一般情况下不用关心内存的申请和释放问题。事实上我也一直没怎么关心过Python的内存管理问题，直到我用了 Python Prompt Toolkit 。这是一个 Python 的CLI组件库，使用简单，效果很好。只是性能用点差，另外就是它居然有内存泄漏。

内存问题产生原因

Python里内存管理主要基于引用计数实现，另外会辅以全图遍历以解决循环引用问题。一般内存问题都是对象被全局变量直接或间接持有导致。出现内存泄漏后关键是找到问题对象到底被谁给持有了。

确认内存泄漏的对象

如果一个程序内存一直异常增长，那多半是存在内存泄漏。接下来就是定位问题了。Python内存分析的工具和手段主要有下面几个：

  1. objgraph 可用现实对象的增长情况。还可以根据对象的引用关系生成图像。
    • 可以根据对象生成引用关系树以及被引用关系树。第一感觉功能很强，实际用下来效果一般。对于复杂一些的项目，生成的关系树是在太过复杂。你以为对象都是通过属性持有，实际上各类的闭包，函数指针等都会持有对象。
  2. pympler 感觉和objgraph差不多，不支持生成图像。
  3. gc.get_referents()/gc.get_referents()/gc.* 获取对象的引用计数及指向该对象的对象，以及其它分析函数。
    • 其它内存分析的库应当都是基于Python的gc模块实现。
  4. print('PromptSession count: ', len([o for o in obj if isinstance(o, PromptSession)])) 打印对象数量，确认是否被释放。

解决内存泄漏问题

要解决内存问题，关键还是找到存在内存泄漏的问题被谁给持有里，然后在需要销毁对象时释放该持有。如果想该对象持有不影响对象的生命周期（比如缓存），可以使用 weakref 库来创建弱引用。

Python Prompt Toolkit 的内存问题

出于性能等考虑 Python Prompt Toolkit 添加来大量的缓存。其中一些看似简单的缓存对象持有了其它对象的函数（函数指针），从而间接持有了其它对象，最终导致大量的对象未被释放。一般情况下一个程序只有一个 PromptSession 对象，该对象贯穿程序的整个生命周期，因此问题不容易察觉。但我的应用时一个服务端程序，需要反复创建和销毁 PromptSession 对象，问题将出现了。

我尝试用 weakref.WeakValueDictionary 改写它的缓存实现，实际过程中发现key和value都会持有对象。

目前的做法是用户断开服务器连接时进行一次缓存的清理。

2021年Python工具链

1. Python虚拟环境：Poetry

一个类似Pipenv的Python虚拟环境和依赖管理的工具，据称改善了一些Pipenv的问题。对我而言，主要看重了Poetry可以对Python库打包的功能。毕竟对我而言书写 setup.py 并不是一件很让人愉快的事情。

2. 代码静态扫描：Flake8

Flake8使用起来非常简单，不用这么配置就可以直接使用，之后检查过程中遇到自己不需要的规则，加个例外就好。

Flake8支持插件，通过添加插件还可以让Flake8功能变的更为强大。

[2023-02 update]: 我的代码检查工具切换成了 ruff 。速度要快很多，且同样易用。

3. 代码自动格式化：Black

写代码时，我个人会尽量遵守 PEP8 ，但难保团队中有些人代码写的有些随意。为保证编码风格的统一，在代码提交前统一由Black对代码镜像格式化。自动格式化之后的代码可能会少了那么一点个性，但为了统一还是值得的。

4. Import规则检查&格式化工具：isort

Black不会对Python 的 import 语句进行排序和分段，这个工作就交给isort来做了。

5. 类型检查：Mypy

长久以来Python作为脚本语言，程序里没有类型信息，很多本可在编译阶段发现的问题被保留到运行时。Python在3.5之后开始支持 Type Hint 了。利用Mypy可以利用这些类型信息对程序进行校验。

6. 单元测试：pytest

相比 unittest ，pytest使用上更为方便。更为重要的是pytest兼容 unittest，似乎没有什么理由来拒绝pytest。 

7. 测试覆盖率：Coverage.py

代码覆盖率测试工具好像也没有第二个选择。

8. pre-commit

在 git commit 时调用flake8进行代码检查，调用black对代码进行格式化等操作。利用pre-commit从源头上杜绝有人把不合格的代码提交到代码库。

9. Docker、Gitlab-CI、GitHub Action、Travis CI

CI服务可根据自己的实际情况进行选择

Python多进程环境下日志模块导致死锁

近期公司的一个Python程序在启动新进程的时候总是会失败。在进程里可以看到对应的进程已经创建成功，但对应代码并未执行，且没有输入任何日志。

通过定位，发现问题源自Python的logging模块，在写文件模式下，logging模块是不支持多进程的。

问题产生原因

Python默认采用Fork方式创建新进程，在Fork新进程的时候会连同 锁 也一同复制到新进程。

  1. 当主进程里有两个线程T1/T2，以及一个锁Lock1。
  2. 线程T2获取了锁Lock1，此时线程T1创建了一个新进程P2，此时Lock1被一同frok给了P2。
  3. P2执行时尝试等待Lock1解锁。由于线程T2不会被复制到P2，没有人给P2线程的Lock1解锁，导致P2死锁。

Python的logging模块在写文件时会加锁，由于锁被复制导致进程死锁。

注：由于创建新进程时锁会被复制，混用多进程和多线程时的加锁操作应当格外小心。

解决方案

根据Python的官方文档，logging模块不支持多进程模式下将日志保存到单一日志文件。多进程模式下日志保存方案，建议参考Python官方文档 Logging to a single file from multiple processes 。

参考资料：

Telegram机器人

最近重新开始玩Ingress。好多年没玩，主要玩家已由QQ转战Telegram了。还有玩家专门为Telegram做了个Bot用来做新人接待、面基统计等相关工作。稍微研究了一下Telegram的Bot实现，发现Telegram API功能非常强大，而且使用起来也很简单，可以轻易的做出自己的机器人。

如果你想更多的了解Telegram Bot可以做什么，怎么创建一个自己的Bot建议阅读Telegram的官方文档 Bots: An introduction for developers。如果你和我一样使用Python进行开发，可以使用python-telegram-bot进行开发。

让Telegram Bot主动推送消息

一般情况下Bot都是在接收到用户的命令后被动的回复信息，如果希望机器人主动推送消息可以先手动查询chat id，然后Bot发送消息时指定为该chat id。获取chat id的方法如下：

  1. 和机器人对话。如果希望获取group的id，这需要先将机器人加到group，再@bot /xxx给机器人发消息。
  2. 访问 https://api.telegram.org/bot<YourBOTToken>/getUpdates获取消息。
  3. 访问getUpdates接口后将得到一组JSON数据，里面哪个是chat id还是比较容易识别出来的。

一个简单的机器人实例

发送命令51job，这个机器人会调用jobmonitor检查51job的岗位更新情况。

import logging
from telegram.ext import Updater, CommandHandler
from telegram.ext.dispatcher import run_async
from job import qcwy as job_qcwy
TOKEN = 'XXX'
# Enable logging
logging.basicConfig(format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
                    level=logging.INFO)
logger = logging.getLogger(__name__)
@run_async
def start(bot, update):
    """Send a message when the command /help is issued."""
    bot.send_message(
        chat_id=update.message.chat_id,
        text="Hi! I'm vicalloy's Bot. \r\n"
        "/51job update 51job. n"
    )
@run_async
def qcwy(bot, update):
    # 为防止其他人恶意向机器人发送信息触发该命令，这里还需要对发送人做个判断，只响应特定用户的请求。
    job_qcwy()
def error(bot, update):
    """Log Errors caused by Updates."""
    logger.warning('Update "%s" caused error "%s"', bot, update.error)
def main():
    updater = Updater(TOKEN)
    dp = updater.dispatcher
    dp.add_handler(CommandHandler("start", start))
    dp.add_handler(CommandHandler("help", start))
    dp.add_handler(CommandHandler("51job", qcwy))
    dp.add_error_handler(error)
    updater.start_polling()
    updater.idle()
if __name__ == '__main__':
    main()

招聘网站岗位信息更新监控工具

项目地址： https://github.com/vicalloy/jobmonitor/

image codecov.io

一个监控招聘网站工作岗位更新情况并发送通知的小工具。很早之前写的一个小脚本，近期重构了一下，让这个脚本可以更方便的扩展。

目前只做了前程无忧以及V2EX的支持，欢迎添加其他网站的支持。

目的

  • 招聘网站的问题
    • 招聘网站每天都会显示大量的岗位更新，但大多岗位都是常年发布，要从这些岗位里过滤出真正更新的岗位并不容易。
    • 招聘网站的搜索功能还不够完善，做不了高度个性化的定制化搜索条件。
    • 专业论坛的招聘版块，几乎没有搜索功能。
  • 这个工具可以做什么
    • 支持定制招聘网站搜索条件，并对网站提供的标准搜索功能进行少量增强。
    • 对检索到的工作岗位进行过滤，如果该岗位之前已发布过，自动忽略。
    • 可部署在服务器上，设置定时任务方式定时推送岗位更新，支持多种消息推送方式。
    • 新工作岗位通知方式支持：显示到控制台、保存到文件、发送到 Slack （强烈推荐 Slack ）。注：如果想支持微信、邮件的通知，需要自行扩展。
    • 内置了 51JOB 和 V2EX 的支持。注：如需要支持其他招聘网站，需要自行进行扩展。

使用范例

  • 初始化项目
$ mkdir jobs
$ cd jobs
$ pip install pipenv --upgrade
$ pipenv --python 3.6
$ pipenv shell
$ pipenv install lbjobmonitor
  • 创建jobs.py。使用python jobs.py执行查询。
  • 可在服务器上使用 crontab 设置定时任务，定期检查
# jobs.py
import os
from lbjobmonitor.message import CLIMessageBackend
from lbjobmonitor.message import FileMessageBackend
from lbjobmonitor.monitor import QCWYJobMonitor
from lbjobmonitor.storage import JobMonitorJsonStorage
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
DATA_DIR = BASE_DIR
def qcwy():
    params = {  # 51job 的查询参数。51job 设置好查询条件后发起查询，通过 chrome 的调试功能查看请求的具体参数。
        'saltype': '',  # 薪资范围
        'keyword': 'python',  # 关键词
        'postchannel': '0000',
        'keywordtype': '2',
        'jobarea': '080200',  # 地区编码
        'pagesize': '5',  # 每页记录数
        '': ''
    }
    storage = JobMonitorJsonStorage(base_path=DATA_DIR)  # 使用 JSON 方式将工作列表保存到当前目录
    message_backend_list = [  # 显示的推送方式
        CLIMessageBackend(),  # 显示到控制台
        FileMessageBackend(fn=os.path.join(DATA_DIR, 'jobs.txt'))  # 保存到文件
    ]
    monitor = QCWYJobMonitor(
        storage=storage, message_backend_list=message_backend_list)
		# monitor.max_page_idx = 1  # 最多查询页数，设置成 1 方便调试
    skip_words = ['AI']
    monitor.monitor_jobs(params=params, skip_words=skip_words)  # 执行查询
if __name__ == "__main__":
    qcwy()

代码导航

  • monitor.py
    • JobMonitor 工作岗位监控基础类
    • QCWYJobMonitor 51JOB岗位监控实现
    • V2exJobMonitor V2EX岗位监控实现
  • storage.py
    • JobMonitorStorage 存储区基础类
    • JobMonitorJsonStorage 将信息以json方式保存到文件的存储区实现
  • message.py
    • BaseMessageBackend 消息发送处理后端基础类
    • IMMessageBackend IM类消息的后端基础类
    • CLIMessageBackend 将消息发送到控制台
    • FileMessageBackend 将消息保存到文件
    • SlackMessageBackend 将消息发送到Slack
    • TelegramMessageBackend 将消息发送到Telegram
  • models.py
    • Job 岗位信息基础数据类
    • QCWYJob 51JOB的岗位信息解析类
    • V2exJob V2EX的岗位信息解析类

注： 还为这个工具做了一个 web 前端界面 https://github.com/vicalloy/jobmonitorweb/ 可通过 web 端查看推送信息。不过个人觉得用 slack 或 telegram 接收和查看推送信息更方便。这个项目里使用了Django Channels来做Web端的实时消息推送，如果感兴趣可以参考一下。

中心化服务问题

最初也考虑过将这个功能做成服务，用户可以通过WEB界面配置自己的订阅规则和消息的接收方式。不过一般网站都会有反爬虫的处理，如果服务器对一个网站访问过于频繁很可能会被该网站给ban掉，这个方案不可行。

当然，如果真想把这个功能做成服务还是有办法的。可以将主要功能用JS实现，用户将数据抓取的规则配置和历史记录保存在服务器。用户打开浏览器手动刷新岗位信息，数据抓取通过用户的浏览器完成。

12306刷票工具

项目地址： https://github.com/vicalloy/12306-ticket-checker

只是在刷出票后发送提醒消息，并不能自动购票。在收到消息后还是得拼手速。 脚本用 Python3 实现，可挂到服务器上 24 小时刷。

前言

总体来说火车票应当是越来越好买，因此一直没怎么太操心。哪知道今年票似乎没有很好买，最近在 12306 刷了几天一张票都没看到。广大抢票软件又都只支持 Windows 系统，作为 Mac 用起来不是太方便。
弄了一个小脚本挂到服务器上，在查询到有符合条件的车票后将通过Slack将消息推送给我。

注意事项

  • 脚本采用python3开发，请使用python3运行该脚本。
  • 在刷到票后，采用 Slack 发送通知消息，因此请先创建Slack的Team。在创建好Team后，创建一个名叫ticket的channel,并申请一个Bot用于发消息。如希望采用其他的通知途径，请自行修改12306.py中的send_message实现。

后记

一大早就刷出了一大波票，不过等我兴冲冲的打开手机客户端一查，连个票的影子都没看到。可能是经过几年的发展抢票市场也日渐成熟，所有的票都在第一时间给抢票软件给刷走了。

TODO

目前这个脚本只能实现余票的提醒功能，但理论上要实现自动购票的功能并会太难。buy.py中给出了登陆的基础实现，不过考虑到实现所有功能所要付出的时间成本因此不打算继续了。
注：也是因为票被秒光的速度太快，估计折腾完也用处不大。

自动购票最大的障碍还是来自于12306的验证码。

验证码的处理思路

手动处理验证码

手动处理验证码应当是最简单有效的处理方式，当前缺点也很明显，无法做到全自动。Slack的API非常强大且易用，通过Slack的”Real Time Messaging API”，我们可以利用Slack实现交互。在需要输入验证码的时候，通过Slack将验证码推送到用户，用户在完成验证码输入后，系统自动处理之后的业务逻辑。

自动识别

要做好验证码的自动识别时间就比手动处理要麻烦多了。如果不是想卖给黄牛我个人是觉得没必要打自动识别的主意了。

12306的验证码可以分为2部分，最顶部的文字以及下方的8张图片。

文字的变形其实并不算太大，相信以现在OCR的水平识别率还是挺高的，重点是下发的8张图片。12306的验证码图小分辨率低，不说机器，要人来识别都不容易。如果纯粹根据机器学习来做图片识别，即使学习库再大效果也不会好到哪去。

最有效的还是”笨方法”，让系统频繁的去请求12306的验证码，然后手工将所有图片打上Tag。考虑到12306的图库不会太小，给图片打Tag必然会有很大的工作量，如果没有利益驱使是百分百做不来的。
另一方面，即使前期做了非常多的准备工作也很难保证12306不会添加新的图片。在遇到不认识图片的时候最简单的方法自然是先将图片记录下来等待手工加Tag，另一方面重新刷新验证换个自己认识的。
Google有提供上传图片进行搜索的功能，可以把图片上传到Google然后得到图片的关键字(当然精确度不会太高)。在图片资料库不够完整的时候也可以利用Google来猜些图。

Python 3的type hints

近年来新出的语言Go、Rust、Swift都无疑例外的是静态类型。随着软件的越来越复杂，动态语言“太过随意”的缺点也越来越明显。此外随着IDE的发展，静态类型语言“繁琐”的缺点也得到了很好的规避。
在学习Swift的时候，Swift的类型推导给了留下了很深的印象。类型推导或许是现阶段兼顾类型检查以及动态语言简洁的最佳解决方案。
Python从3.5开始加入了type hints（类型注释）。

def greeting(name: str) -> str:
    return 'Hello ' + name

从名字“type hints”就可以看出，只是类型注释并不是强制要求。由于只是“注释”，“type hints”需要第三方工具的配合。你需要使用Mypy来对代码进行语法检查。另外PyCharm在新版本中也加入了对“type hints”的支持。

对我而言“type hints”无疑是一个非常棒的特性，让Python也具备了类似Swift的类型推导功能。希望日后的各类Python都能加入type hints的支持。另外就希望各类开发工具可以充分的利用type hints特性。

注：
Swift中使用“?”表示option，Python里则需要写成Optional[str]相比之下有些太过繁琐。

django-lbutils

在Github上公开了不少项目，不过其中大多都算不上“开源”。在我看来开源也应当是一件认真的事情，需要对项目持续的维护，同时也需要提供必要测试用例及文档以保证项目的质量。
最近打算将自用的Django工具组件做个简单的整理然后发布了。为了让项目不要太“随意”，开始补测试用例及文档。因为是自用，测试用例和文档几乎为零。最初只是想简单的修葺，不想真正做起来工作比预期的要高出很多。整了许久代码中的注释依旧很不全，测试的覆盖率都还未达到80%，文档更是没开始动。因为文档还没弄完，所以项目也不算正式发布，如果你感兴趣可以先去看看django-lbutils。
为了这个项目，尝试了一些之前经常看到却一直没怎么使用过的工具。

Tox

Tox是一个Python的自动打包测试用具，用来测试Python库在不同环境下的兼容性。因为是自用，本机环境跑起来是没啥问题。不过在兼容性测试时部分测试用例在Python3以及Django的某些版本下跑起来会有问题。为了搞定兼容性花费了不少时间。

Travis CI

Travis CI是一个在线的持续构建平台。Travis CI会检查你在Github上项目的变化，每当有新push的时候进行自动编译。我现在是每次改动后，直接在Travis CI看测试用例的执行情况。

Coveralls

Coveralls测试覆盖率查看工具。结合Travis CI，可在每次测试完成后将测试覆盖率信息推送到Coveralls。在Coveralls可方便查看当前的测试覆盖率。

Read the Docs

Read the Docs文档托管服务。可从Github抓取文档并自动编译好生成在线文档，目前几乎所有的Python库都将文档托管在上面。