python / python/cpython

Should we test `-X lazy_imports=all` more?

Abierto
#149,640 2 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

3.15 3.16 tests topic-lazy-imports type-bug
Lenguaje dominante
Python
Estrellas
77.2k
Forks
35.9k
Métricas de merge de PR
Métricas de PR pendientes

Descripción

Bug report

Bug description:

Inspired by #149321 I decided to see how well the test suite works with PYTHON_LAZY_IMPORTS=all / -X lazy_imports=all, which makes all imports lazy. It's nowhere near as bad as the none option that we're considering removing, but a few parts of the stdlib are broken, and it seems worth considering if we want to fix these.

Concrete issues I noticed:

  • #144957 breaks test_typing
  • test_unittest fails because unittest.main becomes a module instead of a function.
  • test_struct is broken because of a test that does exec("import struct") in a function; lazy imports are disallowed within functions. Similar issues affect test_enum, test_traceback, and test_future.
  • test_symtable is broken because it fills its _flags list by iterating over globals(), which means it starts containing lazy import marker objects. Similarly test_inspect breaks because it iterates over vars() of a module.

A few tests fail for legitimate reasons; test_compileall tests that an import triggers pyc compilation; test_builtin asserts that __import__ is used when in fact __lazy_import__ gets used.

Full list of failed modules on my machine:

test.test_future_stmt.test_future
test.test_inspect.test_inspect
test.test_pydoc.test_pydoc
test___all__
test__interpreters
test_builtin
test_capi
test_clinic
test_compileall
test_crossinterp
test_datetime
test_enum
test_generated_cases
test_idle
test_import
test_importlib
test_interpreters
test_json
test_lazy_import
test_struct
test_subprocess
test_symtable
test_tools
test_trace
test_traceback
test_tracemalloc
test_typing
test_unittest
test_xmlrpc
test_zipfile
CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs
  • gh-149739
  • gh-151090
  • gh-151105

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza revisando los PR vinculados gh-149739, gh-151090 y gh-151105; después, reproduce los fallos con PYTHON_LAZY_IMPORTS=all o -X lazy_imports=all. Investiga las pruebas de stdlib mencionadas, separando los fallos causados por lazy imports de las pruebas que verifican un comportamiento intencionado. Se considera terminado cuando se haya acordado el alcance y las pruebas relevantes se hayan corregido o se hayan documentado sus fallos esperados.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
python
Área
testing-qa
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.