Warum funktioniert die Python Module kompilieren, aber nicht das Skript ausgeführt wird?

Dateien kompiliert werden, bei der Einfuhr. Es ist nicht eine Sicherheits-Sache. Es ist einfach so, dass, wenn Sie es importieren python speichert die Ausgabe. Sehen dieser Beitrag von Fredrik Lundh auf Effbot.

>>>import main
# main.pyc is created

Beim ausführen eines python-Skript wird nicht verwenden Sie die *.pyc-Datei.
Wenn Sie einige andere Grund, warum Sie wollen, dass Ihr Skript vorkompiliert können Sie die compileall Modul.

python -m compileall .

compileall Nutzung

python -m compileall --help
option --help not recognized
usage: python compileall.py [-l] [-f] [-q] [-d destdir] [-x regexp] [directory ...]
-l: don't recurse down
-f: force rebuild even if timestamps are up-to-date
-q: quiet operation
-d destdir: purported directory name for error messages
   if no directory arguments, -l sys.path is assumed
-x regexp: skip files matching the regular expression regexp
   the regexp is searched for in the full path of the file

Antworten auf Frage Bearbeiten

1. Wenn die Antwort ist möglichen Datenträger-Berechtigungen für das Verzeichnis der main.py, warum Python-Module kompilieren?

   Module und Skripte werden gleich behandelt. Importieren ist, was löst die Ausgabe gespeichert werden soll.

2. Wenn der Grund ist, dass der nutzen minimal sein wird, betrachten Sie die situation, wenn das Skript verwendet eine große Anzahl von Zeiten (z.B. in einem CGI-Anwendung).

   Mit compileall löst dieses Problem nicht.
   Skripte ausgeführt, die von python wird nicht die *.pyc sofern nicht ausdrücklich genannt. Dies hat negative Nebenwirkungen, gut erklärt von Glenn Maynard in seine Antwort.

   Beispiel einer CGI-Anwendung sollte wirklich angegangen werden, indem eine Technik wie FastCGI. Wenn Sie ausschließen wollen, dass der Aufwand kompilieren Sie Ihr Skript möglicherweise möchten Sie eliminieren den Aufwand der Inbetriebnahme python auch nicht zu erwähnen, Datenbank-Verbindung overhead.

   Einem Licht, sein bootstrap-Skript verwendet werden können oder sogar python -c "import script", aber diese fragwürdigen Stil.

Glenn Maynard einige inspiration zu korrigieren und verbessern diese Antwort.

Pädagogik

Ich Liebe und hasse Fragen wie diese auf, SO, weil es eine komplexe Mischung aus emotion, Meinung und gebildete Vermutungen gehen auf und die Menschen beginnen, um schnippisch, und irgendwie jeder verliert den überblick über die aktuellen Fakten und schließlich verliert die ursprüngliche Frage völlig.

Viele technische Fragen auf, SO haben wenigstens eine definitive Antwort (z.B. eine Antwort, die überprüft werden können, indem die Ausführung oder eine Antwort, die zitiert eine maßgebliche Quelle), aber diese "warum" - Fragen haben oft nicht nur eine einzige, definitive Antwort. In meinem Kopf gibt es 2 mögliche Wege, um endgültig beantworten "warum" - Frage in der informatik:

1. Indem Sie auf die source-code implementiert, dass der Gegenstand der Sorge. Dies erklärt, warum " in einem technischen Sinn: welche Voraussetzungen sind notwendig, um dieses Verhalten hervorrufen?
2. Indem bis zu menschlich-lesbaren Artefakte (Kommentare, commit-Nachrichten, E-Mail-Listen, etc.) geschrieben von den Entwicklern beteiligt, diese Entscheidung zu treffen. Dies ist der eigentliche Sinn des "warum", dass ich vermute, der OP interessiert ist: warum haben die Python-Entwickler machen dieses scheinbar willkürliche Entscheidung?

Die zweite Art von Antwort ist schwieriger zu belegen, denn es erfordert immer in den Köpfen der Entwickler, die haben den code geschrieben, vor allem, wenn es keine leicht zu finden, die öffentliche Dokumentation welche erklären, eine bestimmte Entscheidung.

Datum, dieser thread hat 7 Antworten, die sich ausschließlich auf das Lesen konzentrieren die Absicht der Python-Entwickler und dennoch gibt es nur ein Zitat in die Partie. (Und es zitiert einen Abschnitt der Python-Handbuch, das tut nicht Antwort auf die OP-Frage.)

Hier ist mein Versuch der Beantwortung beide von den Seiten der "warum" - Frage zusammen mit Zitaten.

Quellcode

Was sind die Voraussetzungen, dass die trigger-Zusammenstellung ein .pyc? Schauen wir uns der source-code. (Störend, das Python auf GitHub keine release-tags, also werde ich einfach sagen, dass ich freue mich auf 715a6e.)

Es ist vielversprechend code in import.c:989 im load_source_module() Funktion. Ich habe schneiden Sie einige Teile hier für die Kürze.

static PyObject *
load_source_module(char *name, char *pathname, FILE *fp)
{
    // snip...

    if (/* Can we read a .pyc file? */) {
        /* Then use the .pyc file. */
    }
    else {
        co = parse_source_module(pathname, fp);
        if (co == NULL)
            return NULL;
        if (Py_VerboseFlag)
            PySys_WriteStderr("import %s # from %s\n",
                name, pathname);
        if (cpathname) {
            PyObject *ro = PySys_GetObject("dont_write_bytecode");
            if (ro == NULL || !PyObject_IsTrue(ro))
                write_compiled_module(co, cpathname, &st);
        }
    }
    m = PyImport_ExecCodeModuleEx(name, (PyObject *)co, pathname);
    Py_DECREF(co);

    return m;
}

pathname ist der Pfad zu den Modul-und die cpathname ist der gleiche Pfad, aber mit einem .pyc Dateiendung. Die einzige direkte Logik die Boolesche sys.dont_write_bytecode. Der rest der Logik ist nur Fehlerbehandlung. Also die Antwort, die wir suchen, ist nicht hier, aber wir können zumindest sehen, dass code, der fordert, dies wird in einem .pyc-Datei unter den meisten Standard-Konfigurationen. Die parse_source_module() Funktion hat keine wirkliche Relevanz für den Ablauf der Ausführung, aber ich zeige es hier, da komme ich später zurück.

static PyCodeObject *
parse_source_module(const char *pathname, FILE *fp)
{
    PyCodeObject *co = NULL;
    mod_ty mod;
    PyCompilerFlags flags;
    PyArena *arena = PyArena_New();
    if (arena == NULL)
        return NULL;

    flags.cf_flags = 0;

    mod = PyParser_ASTFromFile(fp, pathname, Py_file_input, 0, 0, &flags, 
                   NULL, arena);
    if (mod) {
        co = PyAST_Compile(mod, pathname, NULL, arena);
    }
    PyArena_Free(arena);
    return co;
}

Den charakteristischen Aspekt ist hier, dass die Funktion parst und kompiliert eine Datei und liefert einen Zeiger auf den byte-code (sofern erfolgreich).

Jetzt sind wir immer noch in einer Sackgasse, so lassen Sie uns dieses Konzept aus einem neuen Blickwinkel. Wie funktioniert Python-laden ist es argument und führen Sie es aus? In pythonrun.c es gibt ein paar Funktionen für das laden von code aus einer Datei suchen und ausführen. PyRun_AnyFileExFlags() behandeln können sowohl interaktive und nicht-interaktive, Datei-Deskriptoren. Für die interaktive Datei-Deskriptoren, delegiert er an PyRun_InteractiveLoopFlags() (dies ist der REPL) und für nicht-interaktive, Datei-Deskriptoren, delegiert er an PyRun_SimpleFileExFlags(). PyRun_SimpleFileExFlags() prüft, ob der Dateiname endet in .pyc. Wenn es funktioniert, dann ruft es run_pyc_file() die direkt Lasten kompilierte byte-code aus einer Datei-Deskriptor und dann läuft es.

In der mehr Allgemeinen Fall (d.h. .py - Datei als argument), PyRun_SimpleFileExFlags() Anrufe PyRun_FileExFlags(). Dies ist, wo wir beginnen, finden Sie unsere Antwort.

PyObject *
PyRun_FileExFlags(FILE *fp, const char *filename, int start, PyObject *globals,
          PyObject *locals, int closeit, PyCompilerFlags *flags)
{
    PyObject *ret;
    mod_ty mod;
    PyArena *arena = PyArena_New();
    if (arena == NULL)
        return NULL;

    mod = PyParser_ASTFromFile(fp, filename, start, 0, 0,
                   flags, NULL, arena);
    if (closeit)
        fclose(fp);
    if (mod == NULL) {
        PyArena_Free(arena);
        return NULL;
    }
    ret = run_mod(mod, filename, globals, locals, flags, arena);
    PyArena_Free(arena);
    return ret;
}

static PyObject *
run_mod(mod_ty mod, const char *filename, PyObject *globals, PyObject *locals,
     PyCompilerFlags *flags, PyArena *arena)
{
    PyCodeObject *co;
    PyObject *v;
    co = PyAST_Compile(mod, filename, flags, arena);
    if (co == NULL)
        return NULL;
    v = PyEval_EvalCode(co, globals, locals);
    Py_DECREF(co);
    return v;
}

Der springende Punkt hier ist, dass diese beiden Funktionen im wesentlichen den gleichen Zweck wie der Importeur load_source_module() und parse_source_module(). Er ruft den parser zu erstellen, der eine AST aus Python-Quellcode und ruft dann erstellt der compiler byte-code.

So werden diese code-Blöcke redundant oder machen Sie anderen Zwecken dienen? Der Unterschied ist, dass ein block lädt ein Modul aus einer Datei, während der andere block dauert ein Modul als argument. Das Modul argument ist — in diesem Fall — die __main__ - Modul, welches zuvor erstellt haben in der Initialisierungs-Prozess mit einer low-level C-Funktion. Die __main__ Modul nicht durch die meisten normalen Modul import-code-Pfade, weil es ist so einzigartig, und als Nebeneffekt, es geht nicht über den code, der erzeugt .pyc - Dateien.

Zu fassen: der Grund, warum die __main__ Modul nicht kompiliert .pyc ist, dass es nicht "importiert" werden. Ja, es erscheint in der sys.Module, aber es wird dort über einen ganz anderen code-Pfad als echtes Modul Einfuhren nehmen.

Entwickler Absicht

Okay, so können wir nun sehen, dass das Verhalten hat mehr zu tun mit der Gestaltung von Python als mit jedem klar ausgedrückt Begründung in den Quellcode, aber nicht die Antwort auf die Frage, ob dies eine absichtliche Entscheidung oder nur ein Nebeneffekt, der nicht stört niemanden genug, um Wert zu ändern. Einer der Vorteile von open source ist, dass wir einmal gefunden haben, der Quellcode, die uns interessiert, können wir mit den VCS zu helfen, die Spur zurück zu den Entscheidungen, die led an der derzeitigen Umsetzung.

Einer der zentralen Zeilen code hier (m = PyImport_AddModule("__main__");) stammt aus 1990 und wurde geschrieben von der BDFL sich, Guido. Es wurde geändert im Laufe der Jahre, aber die änderungen sind oberflächlich. Wenn es wurde zuerst geschrieben, das main-Modul für ein script argument initialisiert wurde, so:

int
run_script(fp, filename)
    FILE *fp;
    char *filename;
{
    object *m, *d, *v;
    m = add_module("`__main__`");
    if (m == NULL)
        return -1;
    d = getmoduledict(m);
    v = run_file(fp, filename, file_input, d, d);
    flushline();
    if (v == NULL) {
        print_error();
        return -1;
    }
    DECREF(v);
    return 0;
}

Diese Bestand vor .pyc Dateien wurden auch eingeführt in Python! Kein Wunder, dass das design an, dass die Zeit nicht nehmen-Zusammenstellung berücksichtigt, für die Skript-Argumente. Die commit-Nachricht rätselhaft, sagt:

"Kompilieren" - version

Dies war einer von mehreren Dutzend commits, die über eine Frist von 3 Tagen... es scheint, dass Guido war tief in einige hacking/refactoring und dies war die erste version, die zurück kam, um als stabil. Diese verpflichten, sogar älter als die Schöpfung von die Python-Dev-mailing-Liste von über fünf Jahren!

Speichern der kompilierten bytecode war eingeführt 6 Monate später, 1991.

Diese noch vor der Liste dienen, so haben wir keine wirkliche Vorstellung von dem, was Guido denken. Es scheint, dass er einfach dachte, dass der Importeur war der beste Ort, um hook in der zum Zweck der Zwischenspeicherung von Bytecode. Ob er betrachtet die Idee, das gleiche tun für __main__ ist unklar: entweder es hat nicht auftreten, zu ihm, oder aber er dachte, dass es mehr ärger als es Wert war.

Kann ich nicht finden __main__+pyc&submit=suchen&status=-1%2C1%2C2%2C3" >alle bugs auf bugs.python.org im Zusammenhang caching des bytecodes für das main-Modul, noch kann ich Nachrichten auf der mailing-Liste darüber, so dass anscheinend niemand sonst findet es der Mühe Wert, versuchen Sie es.

Zu fassen: der Grund, warum alle Module kompiliert werden, um .pyc außer __main__ ist, dass es eine Laune der Geschichte. Das design und die Implementierung für wie __main__ Werk wurde fest in den code vor .pyc Dateien noch gar nicht existierte. Wenn Sie mehr wissen wollen als die, müssen Sie die e-mail-Guido und Fragen.

Glenn Maynard ' s Antwort sagt:

Niemand scheint sagen zu wollen, aber ich bin mir ziemlich sicher, die Antwort ist einfach: es gibt keinen festen Grund für dieses Verhalten.

Ich zu 100% Zustimmen. Es gibt Indizien, die diese Theorie unterstützen und sonst niemand in diesem thread hat sich eine einzige Spur der Beweise zu unterstützen jeder anderen Theorie. Ich von Ihnen positiv bewertet werden Glenn ' s Antwort.

Ihre Frage zu beantworten, Verweis auf 6.1.3. "Kompiliert" Python-Dateien in Python offiziellen Dokument.

Wenn ein Skript ausgeführt wird, indem Sie seinen Namen auf der Kommandozeile, der bytecode für das Skript wird nie geschrieben .pyc-oder .pyo-Datei. So, der Start eines Skripts kann reduziert werden durch verschieben von den meisten seiner code in ein Modul und ein kleines Skript, das importiert das Modul. Es ist auch möglich, den Namen ein .pyc-oder .pyo-Datei direkt auf der Kommandozeile.