Care este definiția implementării în limbajele de programare? Ce este CPython? (Inginerie software, Python, Implementări)

Akshay Narwadkar a intrebat.

Am dat peste acest cuvânt „implementare”. CPython este una dintre cele mai comune implementări ale Python. Ce este mai exact o implementare?

M-am documentat puțin despre cum rulează un cod Python. În primul rând, este compilat și convertit în bytecode și apoi, folosind PVM sau un interpretor (nu sunt sigur), este convertit în limbaj mașină care este apoi executat de CPU.

În toate aceste proceduri, unde se află CPython (sau Jython, PyPy, etc.)?

Sunt PVM și interpretorul același lucru?

În al doilea rând, am citit undeva că PVM este scris în C. Este adevărat? Asta înseamnă când se spune că implementarea este în C?

Comentarii

  • Îmi pare rău, am rectificat asta.  > Por Akshay Narwadkar.
  • Doar pentru a oferi un context: pe scurt, computerele sunt proaste. Ele nu știu despre limbajele de programare și alte concepte de nivel superior pe care le folosim, ele știu doar cum să execute un set de instrucțiuni simple. Compilatoarele (cel puțin unele dintre ele, ajutate de linkeri și încărcătoare, de sistemul de operare și de hardware) traduc limbajele de nivel înalt în cod mașină, dar în acest proces generează, de asemenea, o grămadă de cod suplimentar și structuri de date și oferă o anumită logică, toate pentru a susține concepte din limbajele de nivel înalt, cum ar fi obiectele, moștenirea și apelurile de metode virtuale, apelurile de proceduri, chiar și variabilele. –  > Por Filip Milovanović.
  • Pot exista o serie de elemente, straturi și variații diferite în acest sens (timpi de execuție, limbaje intermediare, interpreți, compilatoare JIT, mașini virtuale), dar, în cele din urmă, totul trebuie să se rezume la instrucțiuni de mașină – deci, în acest sens, un limbaj trebuie să fie implementat de un alt cod care va face posibilă executarea programelor scrise în el. –  > Por Filip Milovanović.
  • Aici este CPython: github.com/python/cpython – user214290
3 răspunsuri
Nicol Bolas

Gândește-te la cum funcționează un limbaj uman. În teorie, există un fel de document(e) care stabilește care sunt regulile pentru ceea ce constituie „limba engleză”. Există un set de definiții pentru cuvinte, reguli pentru modul în care funcționează gramatica pentru a asambla acele cuvinte în propoziții cu sens, și așa mai departe. Fiecare dintre noi comunică în limba engleză folosind propriile idei despre ce înseamnă acele cuvinte și despre cum funcționează gramatica engleză.

Deci, putem face o analogie cu limbajele de programare. Aveți un limbaj precum Python. „Oamenii” care „vorbesc” Python în această analogie nu sunt programatori; „vorbitorii” de Python sunt ceea ce noi numim „implementări”. Acestea sunt instrumentele care înțeleg Python și fac ca computerul să facă efectiv ceea ce instrucțiunile Python spun să facă.

CPython este un astfel de „vorbitor” de Python. Cândva, a fost singura implementare Python. CPython este o implementare specifică care este scrisă în mare parte în C. Jython este o implementare a Python scrisă în Java. Ambele fac efectiv același lucru, înțelegând aceeași gramatică pentru același scop. Dar o fac în moduri diferite.

Rețineți că, în primul paragraf, am spus doar că „în teorie” limbajele au un document care definește ceea ce înseamnă. Asta pentru că există multe limbi umane care nu au formale reguli formale. Și chiar și în cadrul regulilor formale, vor exista întotdeauna dialecte, neologisme și alte lucruri, deoarece limbile evoluează în mod natural. Rețineți că acest lucru face posibil ca o persoană care vorbește o limbă să nu reușească să înțeleagă pe cineva care aparent vorbește aceeași limbă.

Acest lucru se întâmplă pentru că cele două persoane, cele două „implementări”, nu sunt de acord cu privire la ceea ce este de fapt limba respectivă.

Limbajele de programare tind să urmeze una dintre cele două căi în ceea ce privește definirea sau „standardizarea”. Ele pot avea un standard de-facto sau un standard de-jure. Într-adevăr, cuvântul „implementare” în acest context înseamnă a „implementa” un „standard”.

Limbajele cu un standard de-jure au un document (documente) dur care stabilește totul despre ceea ce este limbajul respectiv. Să sperăm că acesta specifică în mod formal totul despre limbaj, detaliind în profunzime comportamentul fiecărei construcții sintactice. Dacă două implementări diferă în comportament atunci când li se dă același cod, atunci se întâmplă una dintre următoarele:

  1. Una sau ambele nu implementează corect standardul.
  2. Standardul este slab specificat pentru acea bucată specială de limbaj. Adică, nu spune care ar trebui să fie comportamentul sau este formulat în mod confuz, astfel încât este ambiguu în ceea ce privește ceea ce ar trebui să se întâmple de fapt.
  3. Standardul spune în mod explicit că comportamentul codului este fie definit de implementare, fie complet nedefinit (C++ iubește spune acest lucru).

Rețineți că există un imensă diferență uriașă între o specificație formală pentru un limbaj și documentația de referință.

Un standard de-facto este acela în care se definește limbajul prin alegerea unei implementări și prin faptul că „orice spune acel lucru este limbajul X”. este limbajul X„. Aceasta înseamnă că, dacă două implementări diferă, standardul de facto este cel corect.

Acest lucru înseamnă, de asemenea, că dacă standardul de-facto are ciudățenii în el, fiecare implementare a acelui limbaj trebuie să reproduce aceste ciudățenii. De exemplu, dacă standardul de-facto are o limită fixă de numai 32 de parametri de funcție dintr-un anumit motiv, atunci implementările acelui limbaj care permit mai mulți parametri de funcție sunt greșite din punct de vedere tehnic.

Dacă standardul de-facto are erori (care nu provoacă erori)… ei bine, asta este problema: este nu poate să aibă erori. „Bug” este definit în raport cu standardul. Iar implementarea standardului de-facto este standardul; „bug-urile” din acesta sunt, prin urmare, caracteristici, până când apare următoarea versiune care schimbă lucrurile. Iar astfel de lucruri sunt, la un anumit nivel, modificări ale caracteristicilor limbajului, nu remedieri de erori.

Multe limbaje încep cu standarde de-facto și evoluează spre standarde de-jure. Atât C#, cât și Java au început fără specificații formale ale limbajului, dar ambele le au acum. C++ a fost un amalgam de lucruri prost definite până când C++98 a formalizat ce înseamnă să fii C++.

Python este un fel de jumătate și jumătate în acest moment. Are o document de referință pentru limbaj care încearcă să definească limbajul, dar nu este o „specificație formală”. Din documentul de referință al limbajului:

Am ales să folosesc limba engleză mai degrabă decât specificațiile formale pentru orice, cu excepția sintaxei și a analizei lexicale. Acest lucru ar trebui să facă documentul mai ușor de înțeles pentru cititorul mediu, dar va lăsa loc pentru ambiguități. În consecință, dacă ați veni de pe Marte și ați încerca să reimplementați Python doar pornind de la acest document, s-ar putea să trebuiască să ghiciți anumite lucruri și, de fapt, ați ajunge probabil să implementați un limbaj destul de diferit.

Așadar, în caz de ambiguitate, în general ar trebui să vă supuneți comportamentului CPython. Dar, din nou, există o mulțime de specificații formale care au, de asemenea, zone ambigue.

Comentarii

  • Wow. Frumoasă interpretare a întrebării. Din păcate, mi-am lăsat globul de cristal acasă ieri, când am răspuns la întrebare. –  > Por Robert Harvey.
  • Mulțumesc pentru răspuns. Am înțeles, implementarea este programul care face să ruleze codul python. Dar , puteți să îmi spuneți , vă rog , în următorul proces de conversie unde anume este cpython în lucru (cod python -> compilator -> Bytecode -> PVM(interpretor) -> Machine code) -> Machine code) -.  > Por Akshay Narwadkar.
  • @AkshayNarwadkar: Implementarea Python, oricare ar fi implementare care ar putea fi, este tot ceea ce se află între „cod python” și „cod mașină”. Toate acestea. Este ceea ce face ca un program Python să facă ceea ce ar trebui să facă programele Python. –  > Por Nicol Bolas.
  • ok , mulțumesc ,dar m-a dus la mine o altă îndoială ,AS PVM(interpretul) este scris în „C”, dar dacă implementarea nu este Cpython , PVM-ul continuă să fie în „C” nu este o problemă sau dacă implementarea este jython , are vreun efect în comunicarea sa cu PVM? și apoi cu codul mașină ?  > Por Akshay Narwadkar.
  • @AkshayNarwadkar: Nu sunt piese separate care se amestecă și se potrivesc între implementări. Fiecare implementare oferă toate aceste lucruri. CPython conține o mașină virtuală Python. Jython conține o mașină virtuală Python (sau, mai degrabă, un mediu Python care rulează pe mașina virtuală Java, dar nu contează). Ei nu „comunică” cu ea, așa cum nici tu nu „comunici” cu brațul tău stâng. –  > Por Nicol Bolas.
Bryan Oakley

În linii mari, „Python” este un concept. Este o idee pentru un limbaj de programare. Bineînțeles, este mai mult decât o idee, este o specificație complet dezvoltată a unui limbaj de programare. Cu toate acestea, până când nu există un program real care să poată citi un fișier .py și să execute codul, este doar un concept.

Pentru ca un fișier .py să fie util, acesta trebuie să fie procesat de un program care înțelege limbajul și este capabil să îl convertească în limbajul mașinii de bază.

Atunci când cineva sau o echipă scrie un program care poate procesa un fișier scris în limbajul python (de exemplu: python.exe, /usr/local/bin/python etc.), acel program devine un program implementare a limbajului.

Aceste programe care procesează fișiere .py pot fi scrise în mai multe limbaje. De exemplu, ironpython este un program .net care poate procesa un fișier .py. Jython este un program java care poate procesa un fișier .py. CPython este un program bazat pe C care poate procesa un fișier .py. Fiecare dintre acestea reprezintă o implementare a programului python.

Comentarii

  • Vă mulțumim pentru răspuns. Am înțeles, implementarea este programul care face să ruleze codul python. Dar , puteți să îmi spuneți , vă rog, în următorul proces de conversie unde anume este cpython în lucru (cod python -> compilator -> Bytecode -> PVM(interpretor) -> Cod mașină) -> Cod mașină) -.  > Por Akshay Narwadkar.
  • @AkshayNarwadkar – cpython este toate acestea: compilator -> Bytecode -> PVM(interpretor) -> Cod mașină. –  > Por Bryan Oakley.
  • Bine, mulțumesc, dar, așa cum ați spus, avem nevoie de un program pentru a procesa python și acel program este implementarea. Așadar, nu ar trebui să învăț python, ci cpython (sau orice altă implementare), deoarece cpython mă va ajuta să execut codul python?  > Por Akshay Narwadkar.
  • De asemenea , ,AS PVM(interpretor) este scris în „C”, dar dacă implementarea nu este Cpython, PVM continuă să fie în „C” nu este o problemă sau dacă implementarea este jython, are vreun efect în comunicarea sa cu PVM? și apoi cu codul mașină? – –  > Por Akshay Narwadkar.
Ticklish Soles

Nu sunt familiarizat cu Python, dar bănuiesc că a spune că a spune că CPython este o implementare a Python este la fel ca și cum ai spune că GCC este o implementare a ANSI Standard C și LAM MPI, MPICH, OpenMPI sunt implementări ale specificației MPI. Un limbaj de programare este specificat de un organism de stabilire a standardelor și „implementat” de compilatoare sau interpretoare (sau hibride). C este standardizat de ANSI, care nu este responsabil pentru furnizarea niciunui compilator. Furnizori precum Microsoft sau voluntari precum comunitatea open source dezvoltă compilatoare. Și, în mod obișnuit, un compilator acceptă mai mult decât acceptă standardul, adică extinde standardul (prin oferirea de caracteristici suplimentare) sau „clarifică” standardul, adică definește ceea ce standardul nu definește. De fapt, compilatorul definește o variantă sau un „dialect” al limbajului. În ceea ce privește CPython, bănuiesc că acel compilator/interpretor special este scris în C, de aceea se numește CPython. A se vedea și acest articol.