A Python nem csak a fejlesztők nyelve!

Címkék

A Pythont egyszerűsége miatt előszeretettel használják az üzemeltetők és DevOps szakemberek, tesztelők, illetve az adattudósok is. Február 27-i meetupunkon igyekeztünk számos alkalmazási területről előadót hozni. Ottucsák Józsi például bemutatja mire és hogyan használja a Pythont egy security szakember. További részletek »

Hozzászólások

Szerkesztve: 2020. 02. 18., k - 08:06

/offenz/ellenseges/stb

Nem lattam meg foallasu fejlesztot amelyik ne sikitott volna a pythontol.

Viszont annal tobb olyan nem fejlesztot amelyiknek nem kellene kodot irnia - de ok megis megteszik es ezt Pythonban teszi meg. Amivel nincs baj csak a vegen ne az en asztalomon landoljon a karbantartasi feladat. Csak epp ott landol.

Na lehet nekemesni. :-)

Sikít egy fejlesztő a Pythontól??? Gondolom egy nem-python fejlesztő esetleg, de a statisztikák alapján a világ 2-3. legnépszerűbb nyelve. Szerinted véletlenül használja minden nagyobb cég (Google, Insta, Spotify, Netflix, Uber, stb.), vagy egyszerűen nem lehet benne rendes alkalmazást fejleszteni benne? Nem vagyok hithű Python evangelista, de egyáltalán nem sikítok tőle (most ilyen projekten dolgozom) és igenis nagyon sok mindenre sokkal alkalmasabb egy gyengén típusos nyelv (főleg ha dönthetek úgy, hogy azért mégiscsak legyen benne némi típusosság), mint egy erősen típusos. A Python gyengéje és erőssége egyben, hogy bárki könnyen tud benne egy kis/közepes alkalmazást összedobni, de profik nagy rendszert is képesek építeni benne (és persze, a profik ezt kb. bármilyen nyelven meg tudják csinálni, lásd Ruby/Github,Gitlab vagy PHP/Facebook/Wiki).

Minden korban voltak úgynevezett könnyen használható programnyelvek. FORTRAN (aritmetikai IF-fel és GOTO-val, borzadály), BASIC, Visual Basic, Python stb. Nagyon sok tudományos programot írtak ezeken a nyelveken olyanok, akiket számítógép közelébe sem lett volna szabad engedni.

De ez összességében inkább egy hatalmas pozitívum, nem? Egy magasan képzett programtervező infós nagyon szép, modern kódot fog írni, de kutatni nem fog. Egy kutatónak - aki gyakran 0 programozási tudással rendelkezik - nagyon jól jön, hogy vannak olyan nyelvek, amik könnyen megtanulhatóak és viszonylag egyszerűen összerakható benne a kutatáshoz szükséges kód.

-1

ennyi erovel miert nem a konyvelok irjak a szamlazo programokat? elvegre ok ertenek az adobevallashoz, minek a programozo? de szamtalan peldat lehetne mondani masik szakteruletrol.

nyilvan egy gyors es egyszeru (!!) otlet kiprobalasahoz lehet hogy a kutato irja meg a kis progit, de fennall a lehetosege hogy szarul irja meg igy szar eredmeny jon ki -> nemjo

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Feltételezem nem sok közöd volt eddig az alapkutatáshoz. :D Az előfordul persze, hogy a kód hibás, de pont emiatt szoktak lenni benchmark problémák, amikkel ki lehet próbálni, hogy alapjában véve jól működik-e a kód. Tovább mintha "tanult" programozó nem tudna szar kódot írni. Illetve ott van az az apró probléma még, hogy nagyon kevés helyen engedhetik meg azt, hogy dedikált programozó legyen egy kutatócsoportban (itthon nem is tudnék rá példát mondani, Japánból igen), így vagy megcsinálja a kódolást a kutató maga, vagy mehet más munka után nézni.

Szerintem a kutató érteni fog annyit hozzá hogy meg tudja jól írni kódot, és a tesztelését is el fogja tudni végezni. Akár biológus, akár egyéb más IT-n kívüli terület. A könyvelő messzebb van a területtől. A hatékonyságnál pont az tudja adni az erőt, ha nem kell hogy megjelenjen a teljesség igénye és nagyon alap szinten is alkalmazható egy technológia. Így tud átkötődni más területekre az IT.

Azert a python kodjukat javitani professzoroknak es data scientisteknek sokkal jobb, mint marketinges seggfejek Flash programja miatt szenvedni a weben, mert csak a 100% CPU hasznalatot tudtak elerni, de azt jo konnyen.

Az a szar programozo, aki nem tudja "nem szakember" kodjat elolvasni se pythonban, nem hogy javitani. Ha nincs szarra lambdazva meg szarra fuggvenyvaltozozva feleslegesen, tok karbantarthato, akarki irta.

Nagyon nem ertek egyet a parhuzamoddal, amit vontal. Nem tokeletes nyelv a python, de amit irsz, az egy vicc.

A Python az én esetemben nem szerelem, hanem egyszerűen ezt támogatja a legjoban a Cisco és Ansible, én meg áhlózatokat automatizálok. Innentől kezdve ez nem választás kérdése. Egyébként semivel sem rosszabb, mint más.

Szerintem egy egyszerű és praktikus nyelv, nem véletlen, hogy BigDatában is folyamatosan veszi át a szerepet a Scalatól és természetesen a Java-tól. 

Szeretek is vele dolgozni, de pl most Python kódot kell generálnom és amitől készen vagyok az az, hogy néhány space / tab behúzáson múlik, hogy értelmes-e neki a kód vagy sem. Azt hiszem ez a gyenge pontja. 

 

https://www.faceprep.in/python-indentation/

A tab karaktert nem szabad használni, a tab billentyűt igen, de minden ilyen lenyomás konvertálódjon 4 szóközzé. Ez állítható a szerkesztőkben.

"Azt hiszem ez a gyenge pontja."

Én nem mondanám, hogy ez a gyenge pontja, de a tapasztalatom szerint azok közül, akik ellenségesek a nyelvvel szemben, a legtöbbször ez a hivatkozási alap. Vagyis az elterjedését illetően ez valóban gyenge pont, bár azért milliókat ez sem zavar.

Gondot akkor sem okozott, csak roppant furcsanak talaltam, hogy a szoveg formazasaval tudok csak blokkokat letrehozni.

Valaki egyszer itt a HUP-on irt olyasmit, hogy a python legnagyobb bune az, hogy sokakkal elhitette, hogy tudnak programozni. Tokeletesen fejen talalta a szoget.
Nekem sem magaval a nyelvvel van a problemam, hanem az ecosystem-mel, meg a community osszetetelevel, ami a kulonbozo library-k minosegere van nagy hatassal.
Amikor regen a fonok azzal jott, hogy itt egy python project, be kene segiteni, akkor nem az indentalas volt a bajom, hanem hogy az egesz project egy nagy katyvasz. Lehet, hogy mukodik, de attol meg szar.

"...a python legnagyobb bune az, hogy sokakkal elhitette, hogy tudnak programozni."

Ebben van igazság. De ugyanez a helyzet a festészettel, a fotózással, a zenével, a  szobrászattal stb-vel. Bárki űzheti ezeket kedvtelésből, és ez benne a jó, és ez a jó a Pythonban is. Az hogy ócska pythonos kódot fejlesztett valaki "production" célra, amivel szenvedni kell, nos ...  akkor a megrendelő-átvevő is hibázott. 

Tudnál példát mondani népszerű, de "rossz minőségű" library-re, ami miatt ennyire rossz véleménnyel vagy róla? Lehet én vagyok valami buborékban, de úgy találom, hogy általában elég használhatóak a PyPI csomagok. Az persze itt is előfordul, hogy egy problémára van 2-3 csomag, nagyjából átfedő funkcióhalmazzal és közülük az egyiket már évek óta nem tartják karban. De ez inkább a nyílt forrású fejlesztések velejárója, nem csak a Python gondja. Teljesen amatőrök meg nem library fejlesztéssel fogják kezdeni a nyelv tanulását.

Az NPM-ről meg a left-pad (ha ismered a történetet) típusú csomagokról mi a véleményed egyébként? Ahhoz képest a PyPI messze jobb állapotban van.

Az, hogy nagy projectnél rossz a kód minősége inkább a management és nem a programozási nyelv függvénye. Pl, ha az egyik(?) legtöbb helyen használt C könyvtár kódjából indulunk ki:

  • No central architectural authority
  • 6,740 goto statements
  • Inline assembly code
  • Multiple different coding styles
  • Obscure use of macro preprocessors
  • Inconsistent naming conventions
  • Far too many selections and options
  • Unexplained dead code
  • Misleading and incoherent comments

Please Put OpenSSL Out of Its Misery

Szerkesztve: 2020. 02. 25., k - 11:31

Amit én látok hogy tanulni, 1-pár emberes projektre jó. Amikor egy 50+ fő R&D fejleszt egy terméket arra alkalmatlan.

1. Az identálás a kód része: szoptunk már amiatt mert egy refaktornál véletlen kintebb került egy sor egy mélységgel, fél napig néztük hogy miért nem jó 1 tab megoldotta. 

2. Nincs hozzá megfelelő ezközkészlet sem fejlesztéshez, sem buildeléshez, sem code quality ellenőrzésre. A PyCharm ugyan elég jó de amire egy IDEA képes ahhoz képest fényévekre van lemaradva. Sok próbálkozás után a make bizonyult a leghasználhatóbb build eszköznek.

3. A típusosság hiánya miatt rendszeres az hogy bele kell nézni a hívott library forráskódjába csak hogy megtudjam hogy mit is kell neki beadni, és erre rengeteg idő elmegy.

4. Kevés igazán jó minőségű lib van a PyPi repoban. Volt már hogy a cuccunk a következő verzióval nem ment, volt hogy megváltozott a viselkedés minor verzió emeléskor meg amit el tud képzelni az ember.

5. Python dependency hell,  az egyik csomagnak x verzió kell valamiből a másiknak y és x-el nem működik, mire ezt kikalapálod hajad kihullik és mivel nem lehet egy pyrhon envben több verzió valamiből ezért ez extra munka.

Bottal se piszkálnám a pythont ha nem kéne.

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Szeretném megérteni, hogy miért van az, hogy van, aki azt mondja, hogy egy emberes fejlesztésre alkalmas és vannak nem kicsi cégek akik akár 1000 fős fejlesztéseket is erre tesznek (Google youtube és code backend, Dropbox, Paypal, stb.).

1. Más nyelvekben is lehet szívni apró elgépelésekkel pl.: C++-nál egy apró elírással valamelyik header fájlban.

2. Van hozzá egy rakat eszköz kód quality-hez: pylinttől mypyig. Szinte minden népszerűbb IDE támogat Pythont Eclipsetől VS.Codeig. A PyCharm praktikusan ugyan az mint az IDEA, a dinamikus típusosság miatt tűnhet gyengébbnek a kódkiegészítés, de ha kiírod a típusokat, akkor ugyan az az élmény.

3. A Python erősen típusos nyelv és támogat gradual typingot, amit futtatás előtti típus ellenőrizést tesz lehetővé.

4. A PyPi repróban valóban vannak nem karbantartott csomagok, de szerintem semmivel sem rosszabb a helyzet mint Java maven central vagy NPM fronton. Ez szerintem nem Python specifikus, nekünk állt rendszerünk, mert az új 5.0-ás mysql-jdbc driverben eltoltak valamit a decimal kezelésben...

5. A dependency hellt egyedül OSGi-ban láttam lényegesen jobban megoldva. Nem emlékszem úgy, hogy mondjuk jar-okkal kevesebbet szívtunk.

 

Ha tudunk segíteni Pythonos nehézségek legyőzésében, akkor írj bátran privátban.

1. Igen, csak kérdés, hogy az elgépeléseknek mennyi részét szűri ki a fordító. C++-nál kiszűri majdnem az összeset. Python-nál meg futási idejű hiba lesz belőle, jobb esetben. Vagy az IDE tud szólni róla az esetek egy részében.

 

2. Van megbízható tool refaktoráláshoz pythonhoz? Honnét tudja a tool, hogyha pl. egy fv-t át akarok nevezni, akkora a forráskódban pontosan melyik helyeken szabad átneveznie? Honnét tudja, hogy esetleg egy type annotáció már nem igaz? (Itt inkább kiváncsi vagyok, hogy van-e ilyen megbízható tool, mert én nem ismerek ilyet. Ha te tudsz ilyesmiről, akkor érdekelne, melyik tool/IDE az)

 

3. Akkor, ha minden annotálva van a környéken. Ha nincs, akkor az ellenőrzés nem lesz 100%-os. Ha meg mindent annotálsz, akkor mégis mi az előnye a dinamikusságnak? Arról nem is beszélve, hogy futásidőben a python nem ellenőrzi az annotációk helyességét.

 

Kíváncsi lennék arra, hogy azok, akik tényleg 1000 fős fejlesztéseket tesznek python alá, azok:

1) milyen szabályokat hoztak, hogy karbantartható legyen a kód, ill. könnyen megismerhető.

2) még mindig úgy gondolják-e, hogy jó ötlet volt pythont használni

3) mit csinálnak azzal, hogy piszok lassan fut, mit csinálnak a GIL-lel (azaz nem lehet normális multithreades programot írni cpython alá). Nyilván ez volt az egyszerűbb megoldás, hogy ne kelljen a multithread-es problémákkal foglalkozni, de számomra ezek rendkívül problémásak. Egy egyszerű, pár 10 soros, több szálon letöltő program többszörösére gyorsult attól, hogy multiprocessinget használ multithread helyett. Erre nem tudok mást mondani, mint hogy gagyi.

 

Nekem az a tapasztalatom, hogy kisebb dolgokra jó a python, de egy méret felett egyértelműen a visszájára fordul, és a hátrányok miatt lassú lesz benne a fejlesztés. Eszembe nem jutna pythont használni bármi nagyobbra.

Az Instagramnak van egy remek technikai blogja, ahol ilyesmikkel is foglalkoznak (pl. itt). Több millió soros, Djangora épülő monolitikus kódbázisuk van.

Nem akarok senkit megbántani, de inkább úgy látom, hogy az akarat és a technikai tudás hiánya akadályozza a nagyobb Python programok létrehozását, nem maga a nyelv. Ismerni kell a nyelv gyengeségeit (pl. GIL mellékhatásai) és megkerülni őket. Meg nem kötelező mindenre Pythont használni, nyugodtan lehet a program fele egy másik nyelvvel megoldva és a Pythont csak "ragasztónak" használni. Alapkutatóként pl. írtam pár olyan GPU-n futó szimulációs programot, ahol Pythonnal készült a host kód, a GPU-n futó kódrészletek meg C-szerű OpenCL-ben. A Python cffi-n keresztül érte el a OpenCL C API-ját (amivel pl. egy konkrét kernelt futtattam a GPU-n), ami persze okozott volna egy kis lassulást, de mivel a program nagyrészt úgyis arra várt, hogy lefusson a kernel kód a GPU-n, így összességében nem volt érezhető az overhead. Cserébe sokkal kompaktabb volt a host kód, és az eredményt egyből ábrázolni is lehetett matplotlibbel.

Köszi, ránézek majd a blogra.

 

A GIL-t hogyan kerülöd meg? Szeretnél szálakat használni, hatékonyan, kihasználva a CPU-t rendesen, ahogy azt normális körülmények között lehet. Egyáltalán miféle implementáció/nyelv az, ahol ilyeneket kell kerülgetni? Az én szememben ez nem gyengeség, hanem hatalmas design hiba. Emiatt kevesebb dologra lehet használni a pythont, mintha ez rendesen meg lenne csinálva. Ezt ugye a python3-ban sem fixálták, pedig megtehették volna, ha akarják. Gondolom azért nem, mert a GIL alapból ad valamilyen szintű thread safety-t, és ennek az eldobása fájdalmas lett volna.

 

Matplotlibbel egyetértek, szeretem én is. De mondjuk ez nem a python sajátja, bármelyik programozási nyelvhez lehetne ilyen ábrázoló libet írni.

Számításigényes feladatokra nem nyers Pythont használnék az ismert okok miatt. Szerencsére van pár megoldás. Pl. ha meg tudod fogalmazni a problémádat mátrixos alakban, akkor használhatod a NumPy-t, ami a háttérben C-ben meg FORTRAN-ban írt matematikai könyvtárakat használja. Vagy épp ott van a Numba, ami biztosít egy `@jit()` dekorátort, amit egy függvény elé írva készít belőle egy optimalizált binárist az első futtatásnál, ami már kihasználja a többmagos CPU-kat. Sőt, a Numba arra is képes, hogy GPU-ra "fordítsa le" a kódot (nyilván ez csak bizonyos problémákra jó).

Ha meg van egy web app, aminek időnként hosszabb ideig tartó műveleteket kell végrehajtania, arra használnék egy task-managert (Huey, Celery, Dramatiq, stb.) és annyi workert állítanék be, ami megfelelően kihasználja a hardvert.

Tehát abban egyetértünk, hogy a számításigényes feladatokra a "nyers" Python lassabb, mintha pl. egy optimalizált C kód. A kérdés az, hogy megéri-e Pythonnál maradni és azt gyorsabbá tenni különféle kiegészítéssel, vagy hagyni az egészet és C-ben (vagy egyéb fordított nyelvben) megírni a programot. Ezt a kérdést eldönteni nem egyszerű (pláne egy projekt elején).

Köszi, jó tudni, hogy vannak ezek a megoldások, ha szükségem lesz ilyesmire, akkor tudom mik a lehetőségek.

 

Az a helyzet, hogy van itt egy pythonos kód, ami alapesetben gyorsan lefut (csak 1 adott, kicsi adatmennyiségen kell lefuttatni egy-egy alkalommal). Viszont most az a feladat, hogy a teljes adatmennyiségen le kell futtatni párszor, különböző paraméterekkel (aztán valszeg soha többet). Szóval nem éri meg átírni az egészet C++-ba, mert tovább tartana sokkal, mint maga a pythonos futás. De azért zavar, hogy itt ülök egy sok magos gép előtt, és csak 1 szálat bír használni.

 

Igen, a python lassabb, nem is kicsit. Pláne, ha még a thread-képtelenségét is belevesszük. Nemtom, számomra egyértelmű a döntés: ha egy kicsit is nagyobb a project, és nincs valami python lib, ami jelentősen könnyít a munkán, akkor nem használok pythont. Egyszerűen nincs értelme. Számomra a dinamikus típusosság hátrány. Sokan előnyként említik, de amikor kérek példát rá, akkor sosincs válasz (Lásd itt, ebben a szálban is kértem példát, nem kaptam választ eddig).

Ha a problemadnal a teljes adatmennyisegen belul sem, es a kulonbozo parameterekkel sem parhuzamosithato (mert minden mindennel osszefugg), akkor mas nyelven sem ersz semmit a sok maggal. Ha igen, akkor mar lehet megoldas.

Volt egy kutyu, ami rengeteg csatornan olvasott ADC-bol jovo ertekeket (neuronok elektromos jelet), ennek a feldolgozo programjat irtam. A csatornak - ezen a szinten - fuggetlenek voltak, az egy csatornan egymas utan jovo idoszeletek viszont fuggtek egymastol. A feladat savszures volt, es utana egy adaptiv csucskereses (spike-nak hivjak, amikor egy neuron aktivalodik, es ad egy impulzust), a csucskereso algoritmus mindenfele parametere fuggott a korabbi ertekektol.

Ezt ugy parhuzamositottam, hogy a multiprocessing pool-jat hasznaltam. Volt egy dictionary-m (visszagondolva, lehetett volna object is), ami az adott csatorna belso allapotat tarolta, a feldolgozo fuggvenyem egy ilyen state-et es egy idoszeletet kapott, a visszateresi erteke meg az uj allapot volt a feldolgozas eredmenye mellett. A poolt mindig az epp aktualis allapottal, es a megfelelo idoszelettel etettem, igy a 32 magos gepet 768 ADC csatornaval eleg jol ki lehetett hasznalni (par magot fenntartottam a program tobbi reszere, de 28 mag is gyorsabb volt, mint ha egy magon fut minden).

Valami hasonlot te is csinalhatsz, es viszonylag keveset kellett atirni, hogy tobb magon fusson.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Igen, rogton numpy tombokbe tettem a bejovo adatot, anelkul kb. lehetetlen lett volna. 16 bites mintak, 30kHz mintavetellel, 768 csatornan. Szep nagy szam jon ki, ha osszeszorzod, szoval volt adat. Savszuresre meg a scipy signal moduljat.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Elolvastam az "itt" linken lévő cikket.

Szóval az instások írtak egy python parsert, csak hogy tudjanak írni egy saját lintert és statikus típus ellenőrzőt hogy biztosítsák a típushelyességet.

Lehet végtelen erőforrást beleölni csak hogy működőképessé tegyél egy nyelvet vagy választhatsz egy olyat ami értelmes. Kíváncsi lennék hány mérnökórájuk ment el arra hogy megírják a statikus forráskód elemzőt hozzá csak hogy megfelelő minőségű szoftvert tudjanak készíteni.

Lehet pythonban is igényes kódot írni mint kb bármiben, de sokkal nagyobb önuralmat igényel mint mondjuk egy erősen típusos nyelven.

Vegyük csak a type hintinget, erre még a python hívő kollégám is azt mondta hogy tuti feature. Nagyon jó hogy van de külön figyelned kell rá karban kell tartani mint egy kommentet, mentális energiát emészt fel, és egy olyan IDEn kívül ami felismeri és szól ha nem jó argumentumot akarsz átadni, nem sokat csinál. Ugyan ez egy típusos nyelvnél fel sem merül benned, csak kiírod a típust és nem is gondolsz rá, a fordító megfogja ha bármi nem megengedettet csinálsz, nem kell rá koncentrálnod.

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Nagyon jó hogy van de külön figyelned kell rá karban kell tartani mint egy kommentet

Python 3.5 óta része a nyelvnek, nem kell kommentbe rakni (korábban kommentbe kellett annotálni)

def greeting(name: str) -> str:
    return 'Hello ' + name

Ugyan ez egy típusos nyelvnél fel sem merül benned, csak kiírod a típust és nem is gondolsz rá, a fordító megfogja ha bármi nem megengedettet csinálsz, nem kell rá koncentrálnod.

Ezt beállítani tényleg csak pár perc.

Szerintem iwanabeguru arra utal, hogy a python nem ellenőrzi le. Bármit odaírsz, attól még lefut. Tehát, úgy kell karbantartani, mint egy kommentet.

 

Ha a name típusa megváltozik, akkor egy statikus típusú nyelvben fordítási hiba lesz. Pythonban pedig simán lefut, azaz hazudsz a type annotationnal. Ami gondolom egy mértéken felül az IDE-t is összezavarja, és nem tudja megmondani, melyik hint a hibás.

> Szerintem iwanabeguru arra utal, hogy a python nem ellenőrzi le. Bármit odaírsz, attól még lefut. Tehát, úgy kell karbantartani, mint egy kommentet.

De, ettől miért nehezebb karban tartani, mint egy statikus nyelvnél?

Valóban ellenőrizhetné alapbeállításon is, de annak valószínű indulási sebességben negatív hatása lenne.

> Mert statikus nyelvnél szól a fordító?

Ettől nem lesz nehezebb karbantartani, csak 1-el több lépésből áll a fejlesztési munkament. Ennek az oka annyi, hogy statikus nyelveknél van fordítási folyamat Python-nál nincs.

Mindenesetre szerintem nincs olyan statikus nyelven írt komoly project, ami ne alkalmazna lintert, kód elemzőt és CI-t. Szóval ilyen szempontból kb lényegtelen, hogy a fordítás/futtatás és az elemzés egyszerre vagy külön történik.

Ha van olyan kódelemző pythonhoz, ami megcsinálja a type annotationok ellenőrzését tökéletesen, akkor nincs nagyon különbség a static/dynamic megközelítés között.

 

Vajon van ilyen kódelemző? (Az ugye tiszta, hogy elméletben ilyen nem létezhet, hiszen a változók típusa függet az inputtól)

Igen, az input körül mindig vannak ellenőrző kódok, hogy aztán tovább tudjon menni minden szépen statikus módon. Vagy akár lehet valamennyire dinamikus is, ha pl. valami objectet ír le az a json, akkor vissza lehet adni mondjuk az objectnek az őstípusát. Nyilván ilyesmit a dinamikus nyelvekben is meg lehet csinálni, csak kevésbé egyértelmű, hogy ilyenkor a linter tudja követni, mi történik.

 

Amúgy nem ez volt a lényegi része a hozzászólásomnak, hanem az, hogy vajon van pythonhoz jól működő kódanalizátor? Olyan jól működő, mint amit a statikus nyelvek adnak?

Lehet végtelen erőforrást beleölni csak hogy működőképessé tegyél egy nyelvet vagy választhatsz egy olyat ami értelmes. Kíváncsi lennék hány mérnökórájuk ment el arra hogy megírják a statikus forráskód elemzőt hozzá csak hogy megfelelő minőségű szoftvert tudjanak készíteni.

Igazából egyetértünk. Ha az Instagram mérnökei ma állnának neki nulláról újraírni a teljes backendet, biztos nem Pythont használnának, hanem pl. Rust-ot vagy Elixirt (csak mondtam két random divatos nyelvet). Azonban, ahogy itt is írják:

We initially chose to use Python because of its reputation for simplicity and practicality, which aligns well with our philosophy of “do the simple thing first.” But simplicity can come with a tradeoff: efficiency. Instagram has doubled in size over the last two years and recently crossed 500 million users, so there is a strong need to maximize web service efficiency so that our platform can continue to scale smoothly.

azért választották a Django/Python párost, hogy gyorsan tudjanak haladni a fejlesztéssel, ami kritikus egy startup életének elején. Nekik ez baromira bejött és most már kvázi végtelen erőforrással olyan problémákkal kell foglalkozniuk mint a fent említett statikus típushelyesség-ellenőrző szkript, vagy pl. a garbage collector kikapcsolásával elért 10%-os gyorsulás. Ha C++-szal kezdtek volna neki, most nem kéne típusellenőrző szkriptekkel szórakozniuk, mivel már rég csődbe ment volna az Instagram, mert egy másik cég meghódította volna előttük a piacot. Szóval foglalkoznék én is szívesen a Python gyengeségeinek patkolásával, ha mellette ott lenne a multi-milliárdos cégem, amit e "működésképtelen" nyelvvel hoztam össze. :)

Akkor vajon van arra példa, hogy nagy projectben bevált a python, és jó döntés volt azt használni (csak szakmai indokok alapján)? Ahol nem kellett belefektetni egy csomó plusz energiát a használatába, amit egy statikus nyelv alapból ad? És ki is használják a python dinamikus típusos jellegét?

Tegnap este tartottam a meetupon egy előadást, amiben a CPython sebessége és gyorsítása volt a téma; ez hamarosan szerintem elérhető lesz. Ami még a válaszokban nem hangzott el: a CPython a forrás fájlt ugyan úgy lefordítja, mint a Java vagy C. Amikor kiadod a python3 valami.py parancsot, akkor először fordít és a szintaxis hibák futtatás előtt kijönnek. A dinamikus típusosság miatt a run-time hibák köre szélesebb. A típus annotációk elhelyezése után, mypy-jal lehet statikus típus ellenőrzést végezni.

Azért azt se felejtsük el, hogy a más programozási nyelvek típus rendszere sem szűr ki mindent, lehetne minden függvényhez egy csomó elő- és utófeltételt; vagy pl. osztály invariánsokat megadni.

Érdekesség:

def calc():
	res = 0
	for i in range(1, pow(10, 9)):
		res += i
	return res

Python3: 38s, Pypy3: 1.1s, Numba: 0.18s

Nehezebb feladat (iterátor):

def calc():
	return sum(range(1, pow(10, 9)))

Python3: 10s, Pypy3: 1.1s, Numba: 10s (Warning: cannot determine Numba type of <class 'builtin_function_or_method'>)

Jó látni, hogy lelkesen benchmark-olsz :) Python3-32 vagy Python3-64? Azért érdemes timeit-et használni, mert egy mérés az nem mérés. Az utolsónál kb. az történt, hogy a numba nem tudta jit-elni. Kizárásos alapon a sum lehet neki sok...

Ezt még esetleg megmérheted:

import numpy as np
sum(np.linspace(1, 10**9, dtype=np.int64))

help(np.linspace)

linspace(start, stop, num=50, endpoint=True, retstep=False, dtype=None, axis=0)

Meglepne, ha 50 szamot nem tudna sokkal-sokkal gyorsabban osszeadni, mint egymilliardot. :) Szerintem elirtad. (3.6.9-es CPython, LTS Ubin)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Hát elég masszívan hülyeséget írtam...

numpy.sum(numpy.arange(1, 10**9, dtype=numpy.int64)) akart lenni.

Csak azt akartam mutatni, hogy ha valami hasonlót írunk mint a fenti, és csak ennek az egy sornak a futási idejét nézzük, akkor annak gyorsnak kell lennie, mert nem nagyon fut Python kód. A range értékei szándékosan a másikból voltak véve...

>>> sum(range(1, pow(10, 9)))
499999999500000000
>>> import numpy
>>> numpy.sum(numpy.arange(1, 10**9, dtype=numpy.int64))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
numpy.core._exceptions.MemoryError: Unable to allocate array with shape (999999999,) and data type int64

Ezzel meg az a baj, hogy mire a vilag minden memoriajat lefoglalna, addigra a masik vegez. (otthoni gepemen lefut, abban tobb RAM van, de azert ez megsem a legjobb megoldas.. erzesre nem lett gyorsabb, csak most mar memoriabol is sokat foglal)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Igen, ezzel tisztaban vagyok. Ha a feladat annyi, hogy:

sum(range(1, pow(10, 9)))

(ami fentebb volt) akkor nem kell lefoglalni a tombot. Ezt probaltak optimalizalni kulonbozo trukkokkel. Jo, persze ezt az egyszeru feladatot sokkal egyszerubben (par osszeadassal es szorzassal) is meg lehet oldani, ami koroket ver barmelyik masikra sebessegben is memoriaban:

n=10**9-1
int(n*(n+1)/2)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A kiindulási pont az volt, hogy megnézzem, hogyan teljesít a pypy a cpythonhoz képest. Amúgy az a durva, hogy a clang++-9 kioptimalizálja a kódot az általad megadott képletre. Tehát nem az van, hogyha fixek a határértékek, akkor kiszámolja a végeredményt compile-time. Hanem, nem fixek a határértékek (mert command line paraméterbe adom be), és konkrétan odateszi a ciklus helyére a szummázóképletet.

Úgy 0.008s (gondolom kiszámolja előre)

Hogy egy kicsit valósabb helyzetet nézzük: if (i%2 == 0) res += i;

gcc -O3: 0.6s, python3: 53s, pypy3: 2s, numba: 0.3s

Iterator-os formátumban: sum(i for i in range(1, pow(10, 9)) if i%2 == 0):

python3: 54s, pypy3: 17s, numba: The use of yield in a closure is unsupported.

Igen, ezért tettem a saját verzióban command line paraméternek a határokat, így a gcc nem tudja kiszámolni előre. De mondjuk a clang (mint mondtam az előbb) még így is ki tudja, mert odateszi a szummázóképletet.

 

Megnéztem ez a numba-t, és impresszív: 0.4 sec a i%2-es példára, és 0.2 sec nálam a clang-gal. Ez már csak 2x különbség. Mondjuk nem csoda, mivel a numba mögött is ugyanaz az LLVM van, mint a clang mögött. De mondjuk a numba valszeg csak matek rutinokra jó. Már azt se tudja megemészteni, hogy member függvényre jit-elek (persze lehet, hogy van valami megoldás rá, nem néztem utána). 

Tudom, hogy sebessegben itt mar nem szamit, de ez 1-tol 10**9-1 -ig adja ossze a szamokat. Ugye a range also hatara inkluziv, a felso exkluziv.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Az "ugyan úgy"-gyal azért vitatkoznék. Egy olyan bytekódot csinál belőle, aminek sokkal magasabb szintű instructionjai is vannak, mint egy CPU-nak.

 

A mypy említéséért köszi, megnézem mit tud.

 

Igen, a statikus típusos nyelvek típusrendszere se szűr ki mindent. De egy C++ programban azokat a pontokat, ahol típussal kapcsolatos probléma lehet, kb. az összeset látod (csak rá kell keresni a static_cast, reinterpret_cast szavakra. Ha C-s castokat is használnak - ami ellenjavalt - akkor valami okosabb tool-lal kell végigmenni a castokon).

Jogos... A típusossággal csak azt akartam mondani, hogy relatív, hogy milyen statikus ellenőrzést várunk el. Vannak eszközök/módszerek, amivel a kód futtatása nélkül belátható, hogy megfelel-e specifikációnak vagy sem. Ez szerintem azért nem terjedt el, mert helyességet bizonyítani megtanulni kb. annyi munka mint 0-ról megtanulni programozni és hát a toolingja sem áll túl jól :) Lehetne az az alap elvárás, hogy be is bizonyítottam, hogy működik, nem csak leteszteltem 2-3 esetre.

Nagyon tetszettek a tegnapi eloadasaid!

Elfelejtettem kerdezni, a nem-CPython implementaciok kozul van olyan, ami tamogatja az eval-t, exec-et, es tarsait? (meg ha ez a hivas nem is fut le optimalizalva)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin