PEP 399: exception to remove `io` module Python implementation `_pyio`
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 24/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- operating-systems
Hướng nghiên cứu
Start by reading the PEP 399 exception request and the linked _pyio and io implementation references. Then review the cited I/O testing infrastructure and the pull requests that show divergence between _pyio and _io. Done means the Steering Council has decided whether to grant the requested exception; this is a policy decision rather than a bounded code change.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
CPython currently contains two I/O stacks: _io written in C and _pyio written in Python. I would like a PEP 399 exception to remove _pyio.
- There is no flag to get the
_pyioimplementation as the I/O stack used outside of tests / private import. - The
_pyioimplementation depends on_io. To use it without supporting C the extensions requires patching, (_pyioimportsio,ioimports_iounconditionaly). _pyiouses distinct algorithms from_io. It has significantly diverged over time and getting to matching features takes work (ex. Fix_pyio.BytesIOGC, Match exception in_pyio.FileIO.readall, test_pyio.BytesIO, Match exceptions in open(), make the same copies in .readall(), ...)
Both are currently run in CI by some I/O specific testing infrastructure. _pyio takes significantly longer to execute the same tests, especially on older/smaller machines (ex. Raspberry Pi). I've worked to optimize it but getting faster takes significant core work.
The features needed for fast Python native I/O stacks are well represented by asyncio. In improving _pyio performance asyncio asyncio_tcp got over 10% faster. I think asyncio is representative of in-python I/O performance and has actual users.
I did an audit of open source projects and while some used to use _pyio none use it anymore. PyPy uses the native _io stack.
- Ngôn ngữ chính
- Makefile
- Star
- 182
- Fork
- 35
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của python/steering-council
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
python/steering-council#371 · 2 bình luận · 1 reaction ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 35/100
python/steering-council#370 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 25/100
python/steering-council#369 ·
-
PEP
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
python/steering-council#367 ·
-
PEP
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
python/steering-council#348 · 1 bình luận ·
Tất cả issue của python/steering-council
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
InukaAsith/TwinDesk#84 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
drm/vc4: hdmi: vc4_hdmi_hpd_irq_thread() checks !force_hotplug globally instead of per-connector bitmaskCó thể đã có người làm @popcornmix đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
raspberrypi/linux#7724 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area-System.IO bug untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
dotnet/runtime#136599 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
OS-Simulator-Organization/os-simulator-project#63 ·
Maintainer thường phản hồi trong vòng 1 ngày