HPy - API C được cải tiến cho Python

• HPy là một API mới để mở rộng Python bằng C
• Sử dụng #include <hpy.h> thay cho #include <Python.h>

Ưu điểm của HPy

• Không có overhead trên CPython: Các phần mở rộng được viết bằng HPy chạy với tốc độ tương đương các phần mở rộng "thông thường"
• Nhanh hơn trên các triển khai thay thế: Chạy nhanh hơn trên PyPy, GraalPy, v.v.
• Nhị phân phổ quát: Các phần mở rộng được build bằng HPy Universal ABI có thể được tải trên CPython, PyPy, GraalPython, v.v. mà không cần chỉnh sửa
• Lộ trình di chuyển để trộn với C-API cũ: Có thể trộn các lời gọi C-API legacy với các lời gọi API của HPy. Khi toàn bộ mã đã được di chuyển, có thể biên dịch thành nhị phân phổ quát hoạt động trên mọi phiên bản CPython, PyPy hoặc GraalPy
• Chế độ debug: Giúp dễ dàng xác định rò rỉ bộ nhớ, vòng đời đối tượng không đúng, cách dùng API sai, v.v.
• API tốt hơn: Vượt qua các giới hạn của Python/C API tiêu chuẩn, tạo ra các phần mở rộng nhất quán hơn, chất lượng tốt hơn và được thiết kế để khó phát sinh lỗi hơn
• Khả năng tiến hóa: Như được tóm tắt rõ trong PEP 620, Python/C API tiêu chuẩn phơi bày quá nhiều chi tiết triển khai nội bộ, khiến việc tiến hóa C API trở nên khó khăn. HPy ẩn toàn bộ các chi tiết triển khai nội bộ nên không gặp vấn đề này

Trạng thái hiện tại

• HPy đang được phát triển tích cực. 0.9.0 là bản phát hành alpha mới nhất, nhưng dự kiến sẽ sớm thoát khỏi trạng thái alpha và đang hướng tới một bản phát hành ổn định
• Họ cho rằng HPy ABI hiện đã đủ ổn định để có thể thực hiện cam kết tương thích nhị phân ngược và xuôi trong các bản phát hành sắp tới
• Họ cho rằng API hiện đã bao phủ đủ các trường hợp sử dụng để di chuyển những gói quan trọng (đặc biệt hãy xem bản port của numpy)
• Cũng cung cấp hướng dẫn porting và tài liệu phong phú (đặc biệt là phần tham chiếu API)
• Luôn cởi mở với các thảo luận về thiết kế và những yêu cầu mới

Các phần mở rộng tương thích với HPy

• ultrajson-hpy: mô-đun thực tế đầu tiên được port sang HPy
• piconumpy: đúng như tên gọi, một mô-đun tối thiểu tương tự numpy để định nghĩa kiểu do người dùng tùy chỉnh
• numpy: một trong những mục tiêu đầy tham vọng là port numpy sang HPy và dùng trải nghiệm này để hiểu rõ hơn cách thiết kế API. Bản port này sắp vượt qua test suite
• matplotlib: do còn phụ thuộc vào NumPy nên việc di chuyển sang chế độ phổ quát vẫn chưa hoàn tất hoàn toàn. HPy cung cấp API tương thích legacy để vẫn có thể tiếp tục gọi các hàm C API cũ từ HPy và chạy thành công test suite
• kiwi-solver: một phụ thuộc của Matplotlib, đã được port hoàn toàn sang chế độ phổ quát

Ý kiến của GN⁺

• HPy là một dự án rất hứa hẹn, vượt qua các giới hạn của Python/C API và mang lại khả năng mở rộng cũng như tính di động tốt hơn
• Điểm hấp dẫn đặc biệt là tiềm năng cải thiện hiệu năng lớn trên các triển khai Python thay thế như PyPy và GraalPy
• Việc di chuyển từ C API legacy có thể khó khăn, nhưng HPy cung cấp lộ trình di chuyển dần dần, giúp quá trình này dễ quản lý hơn nhiều
• Khi áp dụng HPy, cần cân nhắc việc tích hợp với hệ thống build và pipeline phân phối hiện có, mức độ chấp nhận của các dự án upstream, cũng như độ trưởng thành và ổn định của chính HPy
• Các dự án khác có mục tiêu tương tự HPy gồm có Cython và PyO3 của Rust. Chúng khác với HPy ở chỗ sử dụng ngôn ngữ bậc cao thay vì C API mức thấp

[GN⁺]

Ý kiến trên Hacker News

• Phần phiền toái nhất khi làm việc với C API là thiết lập các cờ compile/link. python3-config chỉ hoạt động ở cấp hệ điều hành và khó dùng để truy cập các gói được cài qua pip. python3 -m venv không tạo ra các script này, và anaconda/miniconda cũng là vấn đề. Mỗi gói lại làm bẩn script build bằng các lệnh gọi python3 -c "import sys: print..." được hardcode. Tôi đã mở một PR để thêm cờ python3 -m sysconfig --json vào CPython

• Việc ngôn ngữ Python quá tập trung vào một triển khai duy nhất có thể là mối đe dọa đối với thành công lâu dài. Web server, chương trình dòng lệnh và thiết bị nhúng có những yêu cầu khác nhau. Nếu dự án này thành công trong việc thay thế C API của Python bằng thứ không phơi bày chi tiết triển khai, thì việc duy trì các triển khai thay thế và thử nghiệm công nghệ mới có thể sẽ dễ hơn

• Tôi tự hỏi liệu dự án này có cung cấp Python binding độc lập với phiên bản hay không. Hiện tại tôi đang build binding riêng cho từng phiên bản, và điều này tốn rất nhiều thời gian CI/CD

• Sẽ rất thú vị nếu có benchmark so sánh extension HPy với các triển khai Cython/pybind11 về hiệu năng và thời gian phát triển

• Chưa rõ dự án này kết hợp với các thư viện như PyBind11 hay nanobind như thế nào. Có vẻ nếu muốn dùng các thư viện đó theo cùng cách thì sẽ phải viết lại

• Tôi tò mò không biết hiện nay có bao nhiêu extension mới còn được viết bằng C. Tôi cứ nghĩ chủ yếu là Boost Python, pybind, PyO3 và các công cụ tương tự

• Tôi thường đăng về việc triển khai CPython binding với mức overhead tối thiểu, và muốn chia sẻ một vài khuyến nghị, câu hỏi và mối lo ngại. Sẽ tốt hơn nếu cấu trúc lại landing page của dự án HPy và README trong repository. Nếu có số liệu ủng hộ về PyPy, GraalPython và các Python runtime khác thì sẽ thuyết phục hơn

• Việc dùng đối tượng context được đóng gói như HPyContext sẽ hữu ích cho tương lai Python đa luồng hoặc trong các môi trường phức tạp. Nhưng nếu HPyContext bị redirect tới singleton của CPython thì điều đó sẽ không giải quyết được vấn đề

• Benchmark từ năm 2019 có nhắc tới quy ước gọi METH_FASTCALL của CPython nhưng lại không so sánh. Nếu quan tâm đến hiệu năng, tốt hơn là parse đối số trực tiếp từ tuple mà không dùng string formatter

• Tôi tự hỏi trong Python có thứ gì đơn giản giống ffi của luajit hay không, kiểu đưa vào C header rồi load shared library để có thể dùng struct và gọi hàm

• Tôi quan tâm đến việc gọi Go từ Python, và gopy tạo ra Python binding cho cgo. HPy<->cgo có thể sẽ có ít overhead hơn

• Hãy thử tưởng tượng hệ sinh thái Python đã khác đến mức nào nếu công việc này được hoàn thành từ 20 năm trước