30 éves a Python!

Programozás

HB!

És a Marson!

( uid_6201 v | 2021. 02. 20., szo – 15:48 )

Igazi svájcibicska bármi komolyabb feladatra, amit már nem célszerű shellben, sem awk-ban megírni, de a könnyű változtathatósága miatt praktikusabb egy bináris tool-nál.
Linux rendszertoolokra a sorrend részemről várhatólag sok évig ez marad:  shellszkript  -  néha gawk  -  Python(cPython3 vagy PyPy3)  -  Rust, ritkán C.

a sebesseg es fejlesztesi ido forditottan aranyos

Számomra ez volt a fő érv.

Ugyanazt az adatfeldolgozást megírtam C++-ban egy cégnél hetek alatt (az egész cucc volt mondjuk 2-3 hónap, de többet csinált, mint csak az adatfeldolgozás rész). A futási sebesség nagyon fontos volt.

Egy másik cégnél kellett készíteni egy PoC-t egy ügyfél számára, hogy vajon érdekli-e őket egy hasonló adatfeldolgozó. Python-t választottam, mert a futási sebesség nem számított, viszont nem akartam heteken át gépelni. 2 nap alatt megírtam az egészet Python-ban. Persze, 8 másodperc helyett futott egy percig, de ez egy PoC volt, nem számított.

Ez kb. 17-18 éve lehetett.

Már régen nem programozóként dolgozom, de ha magamnak kell valamit összeütni, akkor a Python-hoz nyúlok. (Vagy shell scripthez, ha olyan a feladat).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

a Python kódok legtöbbjét szinte tükörben lehet átírni Rust-ra

Nagyon meglepne, ha ez tényleg így lenne. Az ok, hogy Rust-ban van pár olyan szintaktikai elem, ami valamennyire hasonlít a Python-ra, de ha így "naivan" átírja valaki a Python kódokat Rust-ba, az jó/hatékony Rust kód lesz? Rust-hoz nem értek, de ha valaki mondjuk Java kódot írná át közvetlen Python-ba, az működne, elég rossz minőségű Python kódnak számítana. Azt gondolnám, ugyanez lenne Python->Rust átírás során is.

Na a PHP5 --> 7 is jó példa. Sírtak a webesek, hogy mennyire nagy munka, aztán amikor kényszerből kellett átírni mert végét járta a 10+ éves szerver és az újon már PHP7 volt támogatva, akkor 1 délelőtt megvolt az a kb. tucatnyi honlap átírása. Végülis  mysql -> mysqli és az eregi -> preg_match átírás volt a 95%-a.
Python2 --> 3 ... szintén nagyobb volt a füstje, mint a lángja. Több tizenpáréves céges projektemet dolgoztam át Python3-ra. Itt is 9x% abból állt hogy a print-eket zárójelezni kellett és az xrange()-et range()-re cserélni.
Persze ha vmi spéci 3. féltől származó cuccot importáltál, ami nem létezik Python3 alatt, akkor értelemszerűen szívás. Szerencsére se a webesek PHP produktumai, se a Python kódjaim nem tartalmaztak ilyen 3. féltől származó modult, amely ne futott volna az új verzión.

Sok koncepciókódot megírtam eddig Python-ban, amiből többet a tempó miatt átírtam Rustra. Az tuti, hogy C-re átírni sokkal több meló lett volna a Rust-ra való átíráshoz képest.

pythonnal azert voltak izgalmasabb valtozasok is az xrange atnevezesnel, foleg a string-unicode-chr-unichr-ord-bytearray vonalon, azzal azert lehetett sokat szivni... de az egesz stream/file io is atalakult.

es a "gyari" librarykat is atvarialtak, eleg sokat atneveztek, sok 2.x fv megszunt vagy mar maskepp kell hasznalni/parameterezni. (nem azt mondom hogy ez rossz, mert egyegesitettek az elnevezeseket, parameterezeseket, bejott az async stb, csak az atirasnal ezzel is kulon foglalkozni kellett, ha meg olyat irok aminek py2 es py3 is mukodnie kell na ott azert kell if-ezni rendesen)

pythonnal pont a 3rd party cuccokkal nem volt szivas, amit aktivan fejlesztenek annak reg volt py3 verzioja amit ugyanugy hivnak es ugyanugy kell hasznalni, ott csak akkor van gond ha mar sok eve hanyagoljak es nem adtak ki py3-ra.

php-rol nem nagyon tudok nyilatkozni, de valoban a legtobb esetben a mysqli atnevezes eleg szokott lenni ugy lattam.

+1, py2->py3 váltásnál tudott szívás lenni rendesen.

String títpusokkal volt nekem is gondom. És ilyenkor azért érdemes azt is hozzátenni, hogy ugye dinamikusan típusos nyelv, a hibák nagyrésze runtime derül ki. Simán lehet a printeknél hozzáadtad a zárójeleket, lefut a script és elégedetten hátradőlsz, közben I/O-nál a beolvasott, vagy kiírt fájlba szemét kerül, vagy bizonyos ágon törik csak el a kód majd élesben...

Inb4 "erre valók a unit tesztek": a Python amilyen széles körben használt, azért nem várható el az alapos tesztelés mindenhol...

>ha így "naivan" átírja valaki a Python kódokat Rust-ba, az jó/hatékony Rust kód lesz?

A nagy büdös francokat, legegyszerűbb, pár soros helloworld felett valami típushibán a fordító jó eséllyel elszáll majd. De az a minimum, hogy a borrow checkertől kapsz egy kisregényt, miért szar az egész kód úgy, ahogy van.

Ha nem fibonaccit kell írni demó jelleggel, hanem valós életből vett scriptről van szó, ott pedig úgyis lesz valami nem triviális I/O, amihez valami lib kell (mondjuk XML olvasás/írás), akkor meg már eleve meg vagy lőve, mert full más lesz az API. Ja meg az I/O nem olyan Rustban azért, mint Python alatt. Utóbbinál egy kezdő is simán elboldogul, előbbinél nem feltétlen.

Én nem annyira szeretem, egyedül matekozásra használom, mivel jó modulokat írtak hozzá, numpy, sympy, stb., így erre a célra sztenderd lett a Matlab, Octave, stb. helyett, az R mellett. De szerintem simán túl van hype-olva.

Amúgy mint nyelvet nem szeretem, de ehhez az is hozzátartozik, hogy a legtöbb scriptnyelvet nem szeretem, a PHP-n kívül egyik se szimpatikus, de a PHP-s is webgányolós szutyoknak tartom. Még a klasszikus scriptnyelveket sem szeretm, awk, bash, perl, stb. Az meg kár, hogy C-script nyelvet nem csináltak még, tudom, ott a csh, meg az arbitrary C-style calc C-szerű scriptnyelve. Egyszerűen csak azért, hogy ne kelljen +1 szintaxist fejben tartani.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( Botond | 2021. 02. 20., szo – 20:44 )

És mi van Guido-val? Mintha most a MS-nál dolgozna.

A gugli wikipedia a barátunk:

In October 2019, Van Rossum left Dropbox and officially retired.

On November 12, 2020, Van Rossum announced that he was coming out of retirement to join the Developer Division at Microsoft.

 

...és a saját honlapja:

Distinguished Engineer in the Developer Division at Microsoft, since November 2020.