Na jakiej zasadzie CPython interpretuje Pythona ?

Pytanie z czystej ciekawości :) To do rzeczy..

Czy to działa tak że, napiszę coś w Pythonie i uruchomię przez interpreter CPython to wtedy podczas jego działania, polecenia z Pythona 'zamieniają' się na te z czystego C, i potem na ASM, a na końcu kod maszynowy ? (no bo CPython jest napisany w C)

Albo inaczej..

Gdy użyję IronPythona który jest C#-ową implementacją Pythona to wtedy polecenia z IPY 'zamieniają' się na odpowiadające im w C#, które potem są przetwarzane na CLI ? (bo platforma .NET i C# były wykorzystywane do tworzenia C# to chyba wszystko musi się sprowadzać do CLI c'nie :/ ?)

Jeśli źle myślę to proszę o wytłumaczenie :/

..btw jakby co to - plz nie wrzucajcie tego do 'perełek' ;p

https://speakerdeck.com/brettcannon/from-source-to-code-how-cpythons-compiler-works

CPython zostal napisany w C ale nie kompiluje Pythona do C. On po prostu wykonuje operacje w zależności od wprowadzanych przez ciebie skrytpów. Wyobraź sobie taki kod w C:

int add(char* op1, char* op2){
    return atoi(op1)+atoi(op2);
}

void print(char* msg){
   printf("%s",msg);
}

I teraz wyobraź sobie że parsujesz wpisany przez użytkownika w konsoli tekst. Jeśli tekst wygląda tak: cośtam + cośtam to zapamiętujsz sobie te operandy i wywołujesz funkcje add. A jak tekst wygląda tak: print(cośtam) to wyciągasz sobie to cośtam i wywołujesz funkcję print.

Oczywście mógłbyś kompilować pythona do C a potem kompilować jako C i uruchamiać i są takie rzeczy -> Shedskin ;)

W CPythonie kod Pythona jest zawsze kompilowany do bytecode, jak on wygląda możesz zobaczyć tutaj: https://docs.python.org/3/library/dis.html
Potem, w przypadku CPythona, ten kod jest tylko interpretowany, bo CPython nie ma JITa. Taki PyPy przykładowo ma JITa (Just-In-Time compiler), czyli część bytecodu kompiluje do języka maszynowego, żeby się szybciej wykonywał, a część interpretuje.
Czasami możesz zauważyć pliki z rozszerzeniem .pyc, to jest skompilowany już do bytecodu kod pythona.

IronPython działa analogicznie, tylko zamienia kod Pythona na bytecode dla .NETu (zwany Intermediate Language (IL)) zamiast bytecode dla CPythona ;)

A od czego zależy (w PyPy) która część kodu będzie skompilowana lub nie ? 50% tak, a 50% nie :p ?

@Wizzie Ty chyba nie bardzo rozumiesz czym jest JIT ;) nie słuchaj go @PR1V4T3_R bo głupoty gada chłopak :P

JIT polega na tym, że kompilator może modyfikować kod wynikowy na podstawie analizy w czasie wykonania. Przkład:

Mamy kod który robi:

def fun(x,y):
  return x/y

I teraz jeśli kompilujesz taki kod to na poziomie asemblera będzie po prostu div. CPython będzie to interpretował jako zwykłe dzielenie w C. Ale kompilator JIT może np. zauważyć że w programie zmienna y jest ustawiona na 2 i się nie zmienia i może sobie ten kod zamienić w czasie wykonania na przesuniecie bitowe które jest wielokrotnie szybsze.

Statyczny interpreter po prostu zamienia kod źródłowy na operacje do wykonania. Interpreter z JIT uwzględnia stan w czasie wykonania i zamiany na operacje dokonuje dopiero w chwili wykonania (just in time) :)

Ok, teraz mniej więcej rozumiem :) Teraz mam taki banalny dla was #offtop

Jeśli w Windowsie, shell jest odpowiedzialny za uruchomianie aplikacji (tak było na Wiki :p ), to po co jest w zasadzie platforma .NET :/ ? (platforma na innej yy.. 'platformie' ? (jeśli można za to uznać Windowsowy shell))

To chodzi o to że, metaforycznie framework to taki uniwersalny 'fundament' napisany dla kilku typów procesora (bo każdy ma inny zestaw instrukcji c'nie) na którym stawia się apki skompilowane w tym CIL ? Dobrze to rozumiem ?

JIT chyba może być różnie rozumiane.

Dam przykład z Javy Oraclowej:
JVM startuje w trybie interpretera, ale cały czas ma włączone profilowanie kodu. Często wykonywane kawałki kodu (hotspots - do tego nawiązuje nazwa VMki w Javie) są kompilowane w locie (JIT - just in time) do kodu maszynowego i przy wchodzeniu w te kawałki kodu JVMka przełącza się z trybu interpretowanego na natywny. Oczywiście przy wychodzeniu z tych kawałków przełącza się z powrotem w tryb interpretera. Profilowanie jest odpalone cały czas, wobec czego jeżeli statystyki użyte przy optymalizacji natywnego kodu przestają być aktualne, to dany kawałek kodu jest kompilowany od nowa.

Prawdopodobnie w innych VMkach z JIT działa to bardzo podobnie.

@Wibowit nie no mówimy o tym samym, tylko ze kluczowe w kontekście JIT jest to że kompilacja następuje w runtime więc kompilator ma więcej informacji niż miałby gdyby kompilować statycznie. Bo inaczej to można by wszystko kompilować do kodu maszynowego po prostu skoro szybsze ;)

Gdy użyję IronPythona który jest C#-ową implementacją Pythona to wtedy polecenia z IPY 'zamieniają' się na odpowiadające im w C#, które potem są przetwarzane na CLI

Raczej bezpośrednio na CLI, albo na IL (intermediate language) i z niego na CLI.
Nie ma potrzeby angażować do tego C#.