- A hozzászóláshoz be kell jelentkezni
Hozzászólások
/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. :-)
- A hozzászóláshoz be kell jelentkezni
Megvan a maga helye. Most az jobb, amikor javában írnak olyan többtízezer soros programokat, amik csak más programokat hívogatnak meg?
- A hozzászóláshoz be kell jelentkezni
Minden nyelven lehet igenyes meg igenytelen cuccot is irni.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
nagyon sok mindenre sokkal alkalmasabb egy gyengén típusos nyelv
Tudnál erre példát mondani?
- A hozzászóláshoz be kell jelentkezni
Most hated languages:
- Perl
- Delphi
- Visual Basic for Applications
- PHP
- Objective-C
- CoffeeScript
- Ruby
- C#
- Java
- C++
https://www.infoworld.com/article/3235651/stack-overflow-reveals-the-mo…
- A hozzászóláshoz be kell jelentkezni
Szerintem mielőtt ilyen csacsiságokat mondasz, nézd meg a python 3 szabványt! ;)
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1 Szerintem ez az irány, vagyis minél jobban elrejtjük a komplexitást, így minél nagyobb átjárások lehetnek különböző területek között és ez kell is, mert főleg az interdisciplináris területek hozhatnak komoly előrelépést.
- A hozzászóláshoz be kell jelentkezni
-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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
:DDDDDDDD NAPILOL
nem tudom honnan szedsz ilyen hulyeseget, hogy a kutato majd ert hozza. nem ert. neki nem ez a dolga, nem ez a szakterulete, neki ez egy eszkoz, amiben osszehanyja. forras: van mellettem 200 darab kutato, es idonkent fogom a fejem a kodjaiktol.
- A hozzászóláshoz be kell jelentkezni
Pontosan! Es meg nem is ertik es az igenyesseg se nagyon jellemzo...
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Amikor eloszor kellett python-hoz nyulnom, egyszeruen nem akartam elhinni, hogy a behuzas a nyelv resze. Pedig ekkor (meg) nem voltam ellenseges a nyelvvel szemben, hiszen akkor kezdtem.
Mi lesz a kovetkezo? If blokk csak piros lehet?
- A hozzászóláshoz be kell jelentkezni
Ha manapság is gondot okoz a kód indentálása, az azt jelenti, hogy vagy nagyon rosszul beállított, vagy már >10 éve is elavult fejlesztőeszközökkel dolgozol.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"...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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
6,740 goto statements, Inline assembly code
Ezek mióta problémák?
- A hozzászóláshoz be kell jelentkezni
A goto pl 40 éve, max BASIC-ban volt elnézve, de a gosub ott is menőbb volt.
- A hozzászóláshoz be kell jelentkezni
Ha bizonyos módokon használod a goto-t, akkor nincs vele semmi baj. A linux kernel forráskódja tele van gotoval, mégis működik, karbantartható. Mert nem összevissza használják, hanem bizonyos patterneket követve.
- A hozzászóláshoz be kell jelentkezni
Számomra olvashatóbb a kód ;{} nélkül. Ez személyes preferencia, de nem okoz gondot olyan nyelv sem, ahol ki kell rakni.
Legalább így nem kell azon fightolni, hogy sor végére vagy sor elejére kerüljön a {
- A hozzászóláshoz be kell jelentkezni
A csatolt kód tök jól olvasható a behúzásokkal. De minek az a sorminta a végére?:-)
- A hozzászóláshoz be kell jelentkezni
Jesszusom :D
- A hozzászóláshoz be kell jelentkezni
Ha belegondolok, akkor C style rulez: a kódolási standard miatt be kell kezdeni és utána még zárójelet és pontosvesszőt is kell írni. Bónuszban jól meg lehet szívatni bármelyik kollégánkat, pl.:
if (a > 0)
a = 0;
a++;
- A hozzászóláshoz be kell jelentkezni
Az ilyen kodreszletek miatt talaltak ki a code review toolban a Needs Rework gombot. :)
- A hozzászóláshoz be kell jelentkezni
-Wmisleading-indentation
- A hozzászóláshoz be kell jelentkezni
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
- A hozzászóláshoz be kell jelentkezni
Jó könyv, de sajnos elavult; a Python 2-őt tanítja, ami egy zsákutca.
- A hozzászóláshoz be kell jelentkezni
Lehetséges, itt a 3-as verzió. (bár szvsz az alapok azonosnak mondhatóak,persze érdemes 3-tól indulni a tanulásban.)
https://mtmi.unideb.hu/pluginfile.php/554/mod_resource/content/3/thinkcspy3.pdf
/Z
Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Ha jól értelmezem a problémát, akkor a különböző paraméterekkel történő futások egymástól függetlenek. Ez esetben használhatod a ProcessPoolExecutor context-managert, ami 2 sor hozzáadásával (1 import, 1 ctx. man.) máris kihasználja az összes CPU magot. :)
- A hozzászóláshoz be kell jelentkezni
Sajna nem, mert az új paramétereket az eddigi futások eredményéből számoljuk ki. De köszi ezt a tippet is, lehet hasznos lesz a későbbiekben.
- A hozzászóláshoz be kell jelentkezni
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.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ez izgalmas feladat lehetett: I/O, Python, multiprocessing. Numpy-t is használtál?
- A hozzászóláshoz be kell jelentkezni
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.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ez 44MB/sec. Manapság ez azért már nem olyan nagy sebesség. Bár nemtom hány pólusú szűrőt használtál, de ha nem valami durván elvadultat, akkor ezt simán elviszi egy 10 éves gép is egy magon.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
Mert statikus nyelvnél szól a fordító?
Az elvégzendő "fizikai" munka mind2 esetben ugyanaz, kicserélsz egy szót. De statikus nyelvnél nem kell ezt az eszedben tartanod, mert a fordító rádszól, ha nem okés. Eggyel kevesebb dolog, amire figyelni kell.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
> Az ugye tiszta, hogy elméletben ilyen nem létezhet, hiszen a változók típusa függet az inputtól
Ez statikus nyelvek esetében is csak runtime derül ki és crashel el, ha pl json beolvasáskor az egyik mezőben más típus kerül, mint amit vársz.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"...a CPython sebessége és gyorsítása volt a téma; ez hamarosan szerintem elérhető lesz."
Erről bővebben hol lehet olvasni?
- A hozzászóláshoz be kell jelentkezni
Röviden:
- http://numba.pydata.org/ - CPython mellé lib, egyes function-oket tudsz @jit -elni vele (ebben korábban a multicore és a gpu támogatás fizetős volt, de most már ingyenes)
- https://www.pypy.org/ - CPython helyett, általános megoldás
- A hozzászóláshoz be kell jelentkezni
Ez a pypy nem rossz. Csináltam egy kis példaprogit, összeadja a számokat 1-től 10^9-ig.
Eredmény: python3 87 sec, pypy3: 2.15 sec (mondjuk g++-9: 0.24 sec,, clang++-9: 0.16 sec szóval van még hova fejlődni)
- A hozzászóláshoz be kell jelentkezni
É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'>)
- A hozzászóláshoz be kell jelentkezni
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))
- A hozzászóláshoz be kell jelentkezni
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)
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
>>> 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)
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ez két teljesen különböző feladat. A range() nem foglal egy tömbnek memóriát, ezért nem is lehet vele tömbműveleteket végezni. Az ndarray() meg arra van, hogy készítsünk egy tömböt, kerül amibe kerül, majd számoljunk vele akár órákig.
- A hozzászóláshoz be kell jelentkezni
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)
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
int main(void)
{
long res = 0;
long max = pow(10, 9);
for(long i = 1; i < max; i++) {
res += i;
}
printf("%ld\n", res);
return 0;
}
2.5s (gcc) Nem vagyok otthon C-ben: ez miért lassú?
- A hozzászóláshoz be kell jelentkezni
Add meg neki a -O3 kapcsolót, hogy optimalizáljon.
- A hozzászóláshoz be kell jelentkezni
Ú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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Python3-64, numpy-t direkt nem akartam használni, mert a jit sebességét/korlátait akartam felmérni. Emiatt kicsit csalódás volt a numba.
- A hozzászóláshoz be kell jelentkezni
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.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
Nagyon jó volt az előadás ! THX
For Whites Only meeting room!
- A hozzászóláshoz be kell jelentkezni
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)
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni