python / python/cpython

`"import"` audit hook documentation is misleading

Aperta
#116,840 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

docs
Lingua principale
Python
Stelle
77.2k
Fork
36k
Metriche di merge delle PR
Metriche PR in attesa

Descrizione

Documentation

The documentation for the import statement states that it:

Raises an auditing event import with arguments module, filename, sys.path, sys.meta_path, sys.path_hooks.

However, this is not the case if the target of the import is already in sys.modules, as the audit event is raised only on first import. For imports of Python source, the event fires from import_find_and_load(), which is called from PyImport_ImportModuleLevelObject() only if the module is not already loaded.

The docs seem to suggest that the audit event is associated with the statement, but the docs are wrong.

Promote to bug?

I'm filing this as a documentation issue because the docs are not describing this behavior, but it seems that it may represent a bug in CPython. I'm willing to write a patch either way and would like a core developer to decide if this is a docs problem or a runtime problem.

It seems to me that there are a lot of use cases where a user really does want an audit event for every import statement, regardless of whether or not the module has already been imported. In fact, I found this quirk specifically because of one of these use cases. I had an application running import torch in a place where that (memory-hungry) import needed to be deferred, but the output of my debugging audit hook showed me only the first import (which luckily was still enough information to fix the problem).

If a core developer agrees that it makes sense to raise this event even if the target module is already present in sys.modules, this could be promoted to a CPython bug.

Sample program

# target_program.py
import sys
import hook
sys.addaudithook(hook.audit_numpy_import)

# BEGIN unmodified target program
import numpy

from helper import somefunc  # also runs `import numpy`


def random_array():
    arr = np.random.randint(0, 255, size=(30, 50))

    return arr, somefunc()
helper.py
import numpy


def somefunc():
    return numpy.array([42])
hook.py
import inspect
import sys


def audit_numpy_import(event, args):
    if event != "import":
        return

    TARGET_MODULE = "numpy"

    module, filename, syspath, sysmeta_path, syspath_hooks = args
    if module == TARGET_MODULE:
        stack = inspect.stack()
        target_frame = stack[1]  # index 0 is *this* frame, index 1 is where the audit event happened
        fn = target_frame.filename
        lineno = target_frame.lineno
        print(f"{TARGET_MODULE} imported at {fn}:{lineno}")

Running the above instrument program produces the output:

$ python3 target_program.py
numpy imported at /tmp/whats-importing-that-module/target_program.py:8

Where the output I wanted is:

numpy imported at /tmp/whats-importing-that-module/target_program.py:8
numpy imported at /tmp/whats-importing-that-module/helper.py:1

I've confirmed that I can get the above output if I add sys.modules.pop("numpy") after the first numpy import, but unfortunately this (unreliable!) workaround cannot be used from the audit hook, since the module is not placed there until after the hook has finished executing.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia dalla documentazione dell’istruzione di importazione in Doc/reference/simple_stmts.rst e confronta la relativa formulazione dell’evento di audit con il comportamento descritto in Python/import.c, in particolare import_find_and_load() e PyImport_ImportModuleLevelObject(). Esegui il programma di esempio per riprodurre la discrepanza. Il lavoro è completato quando il progetto ha deciso se si tratta di un problema di documentazione o di runtime e il comportamento rilevante è descritto correttamente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
python
Ambito
documentation
Tipo di issue
Documentazione
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.