Rye！就决定是你了！ Python 环境及包管理工具

涉及 Python 环境及包管理的工具七七八八加起来不下于十几种，看得人眼花缭乱。以至于患有选择困难症的本人还在坚持使用最原始 pip + venv 来构建 Python 运行环境。为了与时俱进，经过多方比较，最后选择了 Rye 作为今后的主力生产工具了。 本来还有一个和 Rye 类似叫做 PDM 的备选工具。最后之所以选择了 Rye 基于以下几点原因： Rye 可……

Pynecone 拔草 附应用的手动部署方法

Pynecone 是一个纯 python 的 Web App 开发框架。它的后端基于 Python 的 FastAPI 框架，前端基于 Node.js 的 Next.js 框架。但使用它不需要书写任何前端代码，可以完全用 Python 一把梭。听上去非常诱人，但实际如何呢？ 一个简单 Pynecone 应用的代码如下： PYTHONimport pynecone as pc class State(pc.State): text: str = 'Hello, World!' def goodbye(self): self.text = 'Goodbye, World!' def index(): return pc.text(State.text, on_click=State.goodbye) app = pc.App(state=State) app.add_page(index, route='/') app.compile() Pynecone 会为每个 Session 维护一个 State 上下文，这个状态数据是……

使用 Nuitka 将 Python 程序编译为 Windows 服务

2023-02-14 更新： 原来 Nuitka 商业版通过插件已经实现了编译 Windows service 的功能，但开源版本不提供此功能。掏钱是不可能掏钱的。本人 fork 了 Nuitka 项目，加入了编译 Windows service 的功能，只要在编译时加入 --windows-service 参数就将 Python 程序能构建成 Windows service 了： SHELLpip install nuitka-winsvc nuitka --onefile --windows-service --windows-service-name=myservice main.py 项目地址： https://github.com/tabris17/Nuitka-winsvc 在前文《Nuitka 编译时注入自定义 C 代码》中介绍了在 Nuitka 编译时注入自……

Nuitka 编译时注入自定义 C 代码

Nuitka 是一款用 Python 实现的 Python 编译器，可以生成独立的可执行文件。其原理是生成 C 代码，然后使用 Scons 调用 C 编译器进行编译构建。据说使用 Nuitka 编译后的程序性能比 CPython 更好，和传统的打包工具 py2exe 与 PyInstaller 相比， Nuitka 的优势相当明显。 Nuitka 的使用也十分简单。比如要将下面的 main.py 文件进行打包： PYTHON# main.py print("Nuitka") 首先安装 Nuitka 和建议安装的三方库： SHELLpip……

Python 3.5 之后的新特性

Python 自 3.5 版本起，至当前 3.11 版本为止，变化相当大，引入了众多的新特性，了解这些变化对编写兼容性代码尤为重要。本文整理的一些版本的重要变化。 Python 3.5 此版本最早发布于 2015 年，最终版本为 3.5.10 ，发布于 2020 年。 [PEP 492] 使用 async/await 语法实现协程 见 PEP 492 。 此特性是 3.5 版本最重大的变化。自此，Python 支持 async 和 await 语法，用于……

快速了解 SOCKS5 代理协议

SOCKS5 是最常见的代理服务协议，服务通常使用 1080 端口，支持代理 TCP/UDP 网络协议。协议由 RFC 1928 定义，也可以阅读非官方翻译的中文版。本文主要用于快速入门，省略了协议中不常用的部分。文中提供了协议的部分 Python 代码实现。 sequenceDiagram title 建立 SOCKS5 代理的流程 participant client as 客户端 participant proxy as SOCKS5 代理 participant dest as 目标服务器 client->>proxy: 连接代理服务器 proxy-->>client: 连接成功 client->>proxy:……

asyncio.DatagramProtocol 收到错误后停止响应

Python 官方文档提供了一个使用 asyncio 创建 UDP Echo Server 的示例，代码如下： PYTHONimport asyncio class EchoServerProtocol: def connection_made(self, transport): self.transport = transport def datagram_received(self, data, addr): message = data.decode() print('Received %r from %s' % (message, addr)) print('Send %r to %s' % (message, addr)) self.transport.sendto(data, addr) async def main(): print("Starting UDP server") # Get a reference to the event loop as we plan to use # low-level APIs. loop = asyncio.get_running_loop() # One protocol instance will be created to serve all # client requests. transport, protocol = await loop.create_datagram_endpoint( lambda: EchoServerProtocol(), local_addr=('127.0.0.1', 9999)) try: await asyncio.sleep(3600) # Serve for 1 hour. finally: transport.close() asyncio.run(main()) 然而，一旦收到运行时错误，该 UDP Server 便会失去响应……

Python asyncio 模块实现简单异步 https 请求

网上关于 asyncio 实现异步 https 请求的代码几乎都是基于Python 第三方库 aiohttp 的，而我仅需要一个无第三方依赖的、能一键运行的简单 Python 脚本。翻了翻官方文档，也没有什么值得参考的 sample 代码。无奈只能自己动手撸一个。 以下示例代码的作用是，请求百度首页，并将响应打印出来。支持 Python 3.7 及以上的版本。 版本一 使用 loop.create_connection() 从……

Python 信号处理在不同平台上的差异

在前文《为何 Windows 下无法用 Ctrl+C 终止 Python 进程》中，虽然解释了产生该现象的原因，但却没有解释为何同样的代码在 Linux 下就可以用 Ctrl+C 来中止。究其原因，是由于在操作系统层面，Linux 和 Windows 对 SIGINT 的信号处理方式不同所导致的。 Python 的底层实现原理 Python 将操作系统或 C 标准库提供的信号处理器称作 Low-level signal handler，Pyt……

Python 的 signal 处理与 print() 的 reentrant call 运行时错误

在前文《为何 Windows 下无法用 Ctrl+C 终止 Python 进程》中，讲解了 Python 信号处理的基本原理。当时为了撰写文章而编写了一些测试代码，在运行某例测试代码时，发生了奇怪的 reentrant call 运行时错误。代码如下： PYTHONimport signal signal.signal(signal.SIGINT, lambda signum, frame: print('test')) while True: print('test') 在程序运行中按下 Ctrl+C，程序抛出 RuntimeError 异常。完整错误信息如下： Traceback (most recent call last): File "test.py", line 4, in <module> while True: print('test') ^^^^^^^^^^^^^……