Dano mi do zrozumienia, że Python jest językiem interpretowanym ...
Ten popularny mem jest niepoprawny, a raczej oparty na niezrozumieniu (naturalnego) poziomu języka: podobny błąd polegałby na stwierdzeniu, że „Biblia jest książką w twardej oprawie”. Pozwól mi wyjaśnić to porównanie ...
„Biblia” jest „książką” w tym sensie, że jest klasą (rzeczywistych przedmiotów fizycznych zidentyfikowanych jako) książki; książki oznaczone jako „kopie Biblii” powinny mieć ze sobą coś wspólnego (treść, chociaż nawet te mogą być w różnych językach, z różnymi akceptowalnymi tłumaczeniami, poziomami przypisów i innymi adnotacjami) - jednak te książki są doskonale może się różnić w niezliczonych aspektach, które nie są uważane za podstawowe - rodzaj oprawy, kolor oprawy, czcionka (-y) użyte w druku, ewentualne ilustracje, szerokie zapisywalne marginesy lub nie, liczby i rodzaje wbudowanych zakładek , i tak dalej i tak dalej.
Jest całkiem możliwe, że typowy druk Biblii rzeczywiście byłby oprawiony w twardą oprawę - w końcu jest to książka, którą zwykle należy czytać w kółko, dodając zakładki w kilku miejscach, przeglądając w poszukiwaniu wskazówek dotyczących rozdziałów i wierszy , itp. itd., a dobre oprawienie w twardej oprawie może wydłużyć daną kopię przy takim użyciu. Są to jednak przyziemne (praktyczne) kwestie, których nie można użyć do ustalenia, czy dany faktyczny obiekt książki jest kopią Biblii, czy nie: wydruk w miękkiej oprawie jest całkowicie możliwy!
Podobnie, Python jest „językiem” w sensie definiowania klasy implementacji językowych, które muszą być podobne pod pewnymi podstawowymi względami (składnia, większość semantyki, z wyjątkiem tych części tych, w których wyraźnie mogą się różnić), ale są w pełni dozwolone różnicować w każdym szczególe „implementacji” - w tym w tym, jak radzą sobie z plikami źródłowymi, które otrzymali, czy kompilują źródła do niektórych formularzy niższego poziomu (a jeśli tak, to w jakiej formie - i czy zapisują takie skompilowane formularze, na dysk lub gdzie indziej), w jaki sposób wykonują te formularze i tak dalej.
Klasyczna implementacja, CPython, jest często nazywana po prostu „Python” - w skrócie - ale jest to tylko jedna z kilku implementacji o jakości produkcyjnej, równolegle z IronPython Microsoftu (który kompiluje się do kodów CLR, tj. „.NET”), Jython (który kompiluje się do kodów JVM), PyPy (który jest napisany w samym Pythonie i może kompilować do ogromnej różnorodności formularzy „zaplecza”, w tym języka maszynowego „just-in-time”). Wszystkie są Pythonem (== „implementacje języka Python”), tak jak wiele powierzchownie różnych obiektów książkowych może być Biblią (== „kopie Biblii”).
Jeśli interesuje Cię konkretnie CPython: kompiluje pliki źródłowe w specyficzną dla Pythona formę niższego poziomu (znaną jako „kod bajtowy”), robi to automatycznie, gdy jest to potrzebne (gdy nie ma pliku kodu bajtowego odpowiadającego plikowi źródłowemu lub plik kodu bajtowego jest starszy niż kod źródłowy lub skompilowany w innej wersji języka Python), zwykle zapisuje pliki kodu bajtowego na dysku (aby uniknąć ich ponownej kompilacji w przyszłości). OTOH IronPython zwykle kompiluje się do kodów CLR (zapisując je na dysku lub nie, zależnie) i Jython do kodów JVM (zapisując je na dysku lub nie - użyje .classrozszerzenia, jeśli je zapisze).
Te formularze niższego poziomu są następnie wykonywane przez odpowiednie „maszyny wirtualne” zwane również „tłumaczami” - odpowiednio CPython VM, środowisko uruchomieniowe .Net, Java VM (inaczej JVM).
W tym sensie (co robią typowe implementacje) Python jest „językiem interpretowanym” tylko wtedy, gdy C # i Java to: wszystkie mają typową strategię implementacji polegającą na wygenerowaniu kodu bajtowego, a następnie uruchomieniu go za pomocą maszyny wirtualnej / interpretera .
Bardziej prawdopodobne jest skoncentrowanie się na tym, jak „ciężki”, powolny i uroczysty jest proces kompilacji. CPython został zaprojektowany do kompilacji tak szybko, jak to możliwe, tak lekki, jak to możliwe, przy możliwie jak najmniejszej ceremonii - kompilator bardzo mało sprawdza i optymalizuje błędy, dzięki czemu może działać szybko i przy małej ilości pamięci, co z kolei pozwala mu uruchamiać się automatycznie i przejrzyście, gdy zajdzie taka potrzeba, bez konieczności nawet uświadomienia sobie, że przez większość czasu trwa kompilacja. Java i C # zazwyczaj akceptują więcej pracy podczas kompilacji (a zatem nie wykonują automatycznej kompilacji) w celu dokładniejszego sprawdzania błędów i przeprowadzania większej optymalizacji. To kontinuum szarych łusek, a nie sytuacja czarno-biała,
