python / python/cpython

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

Ouverte
#149,640 2 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

3.15 3.16 tests topic-lazy-imports type-bug
Langage dominant
Python
Étoiles
77.2k
Forks
35.9k
Métriques de merge des PR
Métriques de PR en attente

Description

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

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par examiner les PR liés gh-149739, gh-151090 et gh-151105, puis reproduisez les échecs avec PYTHON_LAZY_IMPORTS=all ou -X lazy_imports=all. Étudiez les tests stdlib mentionnés en séparant les échecs causés par les lazy imports des tests qui vérifient un comportement intentionnel. Le travail est terminé lorsque le périmètre est convenu et que les tests concernés sont corrigés ou que leurs échecs attendus sont documentés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
python
Domaine
testing-qa
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.