[python] prednosti in slabosti

Torej uporabnik OwcA me je z svojo odlčno izjavo, da bi za rešitev tegale problema bil najboljši python napeljal k dajanju da spišem tole temo .

Torej zanima me kakšne so prednosti ter slabosti tega jezika, zakaj izbrati python in zakaj ne, kter IDE je najboljši. Kolikor sem jaz gledal že nekaj kode spisane v pythonu, se mi sintaksa ne dopade preveč, ker se nekako ne znajdem, ker ni nikjer zaključka kot pri C-like sintaksi (mogoče sem preveč na to sintakso navajen), kjer imaš vso kodo, na katero vpliva if stavek v oklepajih... ne vem mogoče kakšen IDE ponuja boljšo preglednost??

In ker je v pythonu tudi funkcija neke vrste objekt, je python kot nalašč za funkcijsko programiranje ( Functional programming). Ne mešat tega s proceduralnim. Funkcijsko je bolj kewl

@drola: uporabi [ st.koda] [ /st.koda]

Sicr pa sei OK ampak tile zamiki pa to nekako mi ne deluje pregledno, ker editorji ti pri C-like sintaksi, ko se postaviš pred { oba začetni in končni oklepaj obarvajo, tako točno veš do kam sega en stavek, tukaj pa neki zamiki

Pluse in minuse je lažje naštevat, če malo bolj konkretiziramo s čim primerjamo. V splošnem pa:

+ funkcije so prvorazredni objekti
+ izrazna moč
+ preglednost
+ preprostost, razumljivost
+ metaprogramiranje
+ standardna knjižnica
+ tuje knjižnice
+ uporabniška skuponist
+ povezljivost z drugimi jeziki (zlasti, če upoštevamo še IronPython in Jython)
+ interaktiven interpreter (REPL)

- ponekod nesmiselne omejitve in konvencije
- preveč knjižnic (ni jasne izbire IDE-ja, spletnega ogrodja, GU, ...)
- hitrost (ni grozno počasen kot recimo Ruby, ampak vseeno prepočasen, da bi bil uporaben za vse)

Malo je področji, kjer je Python najboljši, je pa odličen kompromis.

Npr. v funckiji ustvariš instanco objekta Avto in jo naslavljaš preko spremenljivke mojAvto. Ko je funkcije konec, te instance ni nikakor več mogoče nasloviti, zato gre v garbage collection, kjer čaka na cikel čiščenja pomnilnika in ko se to zgodi, se sprosti pomnilnik, ki ga je ta instanca zasedala (oz. tako nekako). V C(++) bi ta pomnilnik ostal zaseden, v kolikor ne bi programer pazil, da sprosti prostor.

Objekti ki jih narediš na skladu se pri stack unwindingu pobrišejo implicitno, tako da si podal zelo slab primer. To bi veljalo le za ustvarjanje objekta na kopici, za kar pa se ponavadi uporabljajo pametni kazalci in podatkovne strukture v C++ standardni knjižnici (prek allocatorjev). Garbage collection je pač le eden od načinov za upravljanje s pomnilnikom, ki pri nekaterih jezikih ni najboljša pot. Ni niti + niti -.

- hitrost (ni grozno počasen kot recimo Ruby, ampak vseeno prepočasen, da bi bil uporaben za vse)
Če si soočen s performančnimi omejitvami ti seveda nihče ne bo preprečil, da ne bi uporabil C++-a za komponente, ki jih nato uporabljaš v Pythonu.

Še en + "deluje na praktično vseh aktualnih platformah" in še eden IDE: eric3.

Enostavno povedano, dobri stari C je rekel tako. Imamo statični pomnilnik, kopico in sklad. C++ je ta model podedoval in programerju prepušča umazano delo.

1. sklad:

int main(int argc, char** argv) {
   MojObjekt m;
}

V vsakem scope-u (funkcija, stavek, zanka, izjema) se izvrši stack unwinding. To pomeni da se avtomatsko kliče destruktor objekta MojObjekt.

2. kopica:

int main(int argc, char** argv) {
   MojObjekt* m;
   m = new MojObjekt;
}

Tukaj je ta klasični problem ko naš program neslavno "spusti" pomnilnik.

Ker je sklad omejen in ga ne moremo širiti ali zmanjševati, potrebujemo kopico. Kako narediti upravljanje s pomnilnikom bolj robustno ?

Nekateri jeziki, kot je Python so rekli. Hitrost razvoja je pomembnejša od hitrosti, zaradi česar bomo v našem prelepem jeziku uporabljali smetarja implicitno (vedno bomo uporabljali kopico, razen če sam Python uspe katero zadevo nekoliko zoptimizirati in jo vreči na sklad). Tako so pod preprogo pometli celoten problem, ter na grob z imenom "RIP memory leak" zalili betonsko ploščo (ki občasno vseeno prepušča vodo, če je programer dovolj kreativen). Zaradi tega so v takih jezikih destruktorji praktično neuporabni (kolikokrat vidite finalize funkcijo v Javi ?).

Ker je C++ nižjenivojski jezik od npr. Pythona si pomagamo z drugačno metodo, ki jo lahko na grobo opišemo kot RAII. Zanašamo se na konstruktorje in destruktorje pri objektih, da bodo ti zajeli in uničili pomnilnik na kopici. To pomeni da imamo na skladu majhno število objektov (tu se spomnite se na stack unwinding), ki v destruktorjih uničijo ves zajet pomnilnik avtomatsko, tudi če pride do izjeme (le v destruktorjih in izjemah samih ne sme priti do nove izjeme).
Po enakem kopitu se delani auto_ptr, vector, stack, map v C++ standardni knjižnici.

Npr.:

auto_ptr<MojObjekt> m(new MojObjekt);

Ko gre ta pametni kazalec iz scopa se izvede njegov destruktor, ki uniči MojObjekt.

Če si s sedaj predstavljamo kako deluje smetar dobimo enostaven algoritem, ki pregleda seznam vseh pametnih kazalcev in vsakega, kjer je število referenc na objekt enako 0 (ali kjer je seznam referenc prazen), izbriše iz seznama. Seveda pa je uporaba le-tega v Pythonu skrita in tako bistveno lažja za programerja.

Danes zjutraj sem dobil fortune, ki nekaterim lahko razloži, zakaj je Python tako kul.

The tao that can be tar(1)ed
is not the entire Tao.
The path that can be specified
is not the Full Path.

We declare the names
of all variables and functions.
Yet the Tao has no type specifier.

Dynamically binding, you realize the magic.
Statically binding, you see only the hierarchy.

Yet magic and hierarchy
arise from the same source,
and this source has a null pointer.

Reference the NULL within NULL,
it is the gateway to all wizardry.