PEP 399: exception to remove `io` module Python implementation `_pyio`
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 24/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- python
- Área
- operating-systems
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Makefile
- Estrellas
- 182
- Forks
- 35
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de python/steering-council
-
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
python/steering-council#373 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
python/steering-council#371 · 2 comentarios · 1 reacción ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 35/100
python/steering-council#370 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 25/100
python/steering-council#369 ·
-
PEP
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
python/steering-council#367 ·
Todos los issues de python/steering-council
Issues similares
-
DPI change is not fully handled in the cascading window on WindowsPosiblemente ocupada @yukawa la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
grumpycoders/pcsx-redux#2530 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
omacom/omarchy#17042 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
4.0 bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
microsoft/azurelinux#19834 · 1 comentario ·
Los mantenedores suelen responder en 1 día