Python komoly projektre

Szkriptek: Python, Perl, Bash, ...

- Írt már valaki komolyabb programot python-nal? Én eddig csak kisebb dolgokra, pluginozásra használtam. Érdekelne, hogy kinek milyen tapasztalata van.

- Van egy új projektem a fő irányvonal a hangfelismerés és fotó analizálás. Érdemes-e ilyen témákra pythont használni?

  • 22793 megtekintés

( Refresh | 2012. 12. 05., sze – 09:37 )

Én is inkább csak "subscribe"... :)
A saját véleményem: nem mernék belevágni, max. ha van olyan fordítód, ami tisztességes gépikódot állít elő a python programból.

( emberk | 2012. 12. 05., sze – 09:38 )

Mellékszál, de ha fénykép analízis, akkor az opencv beépíthető a python kódba. Én C-vel, és C++-al használom, nagyon jó cucc. Azt hogy a python mennyire alkalmas erre, fogalmam nincs.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( tetra | 2012. 12. 05., sze – 09:44 )

A meld Pythonban íródott, nem tudom neked mi számít komolyabb programnak. Mondjuk ilyen hardcore matekos problémákra, mint a képanalizálás nem használnám, ellenben a frontend megírására tökéletes, és csak azt az 1-2 függvényt kell megírni C++-ban.
----
India delenda est.
Hülye pelikán

+1

Képfeldolgozással foglalkook pár éve, python lassú lesz, szinte tuti. Viszont frameworkre tökéletes.

Persze, ha nem real time a feladat, akkor játszhat. Viszont, ha nem vagy profi C++-ban, akkor inkább bele se kezdj, mert évekig tart, amíg beletanulsz, szóval ez is a python mellett szól.

( szeim v | 2012. 12. 05., sze – 10:05 )

Szerintem igen. Idáig nem volt gondom az OOP részével (bár főként django miatt használom), a nyelv "nem áll az utadba".

Külön szeretem, hogy rá vagy kényszerülve a normális indentálásra. Erről jut eszembe: nem tudom mennyire hosszútávú lesz a project, de ne használj tab karaktereket a kódodban. :)

Amit nekem szokni kellett, az a "duck typing".

Néhány könyv: http://www.mindview.net/Books/TIPython (ingyé)
http://www.amazon.com/Quality-Python-Development-ebook/dp/B0080YHBR8/ (ezt sokan dícsérik)

Fotóanalizálás:
Az opencv-nek van python binding-je
http://opencv.willowgarage.com/documentation/python/index.html

Hangfelismerés:
Itt nem tudok jó tippet adni, viszont a numpy/scipy http://www.scipy.org/ és a http://pybrain.org/ lehet hogy érdekes lehet neked.

Ezenkívül van QT binding is: http://wiki.python.org/moin/PyQt A példák alapján (persze egy "alap", c++-os qt howtot érdemes előtte végigolvasni, még ha nem is csinálod végig) elég könnyedén össze lehet dobni vmi grafikus felületet.

Mindent összevetve: Ha a számításigényes feladatokat ki tudod "exportálni" a lib-ek szintjére (Azaz pl. egy élfelismerő algoritmust nem python-ban kódolsz le, hanem vmi kész opencv metódust használsz) akkor szerintem javallott ez irányba menni.

Ha a későbbiekben mégis gyorsítani kell a programot, az nagyon nagy valószínűséggel megoldható egy-két metódus c/c++-ben való implementálásával. Így gyors lesz a kód, de nem kell mindent c++-ban összegányolni: http://wiki.python.org/moin/IntegratingPythonWithOtherLanguages

Így hamar el tudsz készíteni vmi működőt, és nem fogsz elvérezni idő előtti optimalizálással.

Persze hozzá kell tennem, hogy elfogult vagyok, ha pythonról van szó. :)

http://qt.digia.com/Product/Licensing/License-Comparison/
nekem ez a legfontosabb:
"Application source code can be private when linking dynamically"
Egyszer már megbeszéltük a változás után(most már látom, hogy 4.5-nél váltott), hogy nem kell ingyenesnek lennie a szoftvernek és lehet zárt a forráskód, ha dinamikusan van linkelve. Persze figyelni kell a többi feltételre is.

Én egy szállítólevél készítő programot írtam úgy, hogy PyQT és PySide-al is megy. Alig kellett a kódba alternatívát írni! Gyakorlatilag ugyanaz a kód fut mind a kettőn és csak nagyon kevés helyen kellett ellenőrzést betenni, hogy éppen a PySide vagy a PyQt specifikus kódrészlet fusson.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Mindenekelőtt nem akarok flamewart. :)

Ezért:
http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Nem szabvány, de _nagyon_ ajánlott, különösen nagyobb lélegzetvételű programoknál.

A saját tapasztalat is ez: többedmagammal örököltem egy pythonban írt projectet, és az elején rengetegszer tört el az éppen aktuális verzió. Aztán kiirtottuk a tabokat, a gitben beállítottuk hogy ne tudjon senki se kommitolni olyan fájlt amiben tab van.
A cucc meg elkezdett működni.

Igazából nem mindegy, mert a tab az egy csalafinta karakter, ugyanis a vizualizációja nem egységes, minden editor úgy jeleníti meg, ahogy jónak látja, míg a szóköz azért többnyire egy üres karakter.
----
India delenda est.
Hülye pelikán

Egy editoron belul igen. De egy projektet altalaban nem csak egy ember visz. Es ha valakinel tortenetesen 8 szeles a tab, de amugy meg 4 szeles szokozoket hasznal, abbol nagyon vicces helyzetek adodnak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ezert kell egy jo editor, ami felismeri (vagy magatol, vagy kommentekben elhelyezett rasegitessel), hogy mit hasznal a file, es ha az ember tabot nyom, akkor a megfelelo karaktersorozatot teszi be, lett legyen az tab karakter, 2, 3, 4 vagy 9 space vagy barmi.

A tab, mint billentyu, tok jo. Az editor meg azert is van, hogy ne kelljen torodnom azzal hogy hogyan indentalok, mert igazabol nagyivben nem erdekel.

--
|8]

Persze, ebben igazad van, a problema nem is ez, hanem az, amikor emberek _rossz_ editorokkal esnek neki egy python forrasnak, es inkonzisztens lesz. Nem volt az egeszen veletlen, hogy ahol Pythonnal dolgoztunk, ott mindenkinel ki volt kenyszeritve az Eclipse hasznalat, akkor is, ha szegeny borzalmasan pocsek volt, mert viszonylag surun osszehanyta magat, cserebe nem volt indentalasi problema soha. Talan osszesen ket NetBeans-es ember volt a csapatban, de ok reszben nagyon ritkan commitoltak, reszben meg folyamatosan futtattak/kattintotak az appot, fenysebesseggel derult ki, ha gond volt - es altalaban csak az o gepukon crashelt az app.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Erre van egy olyan mondas, hogy szocialis problemat (ti. hogy a T. delikvens nem kepes normalisan indentalni) technikai korlatozasokkal megoldani butasag. Le kell torni annak a kezet aki elbassza, vagy commit hookkal kikenyszeriteni a megfelelo indentet. Nagyon hamar meg tudjak tanulni az emberek a coding stylet. :)

--
|8]

Alapvetően azért van egységes coding guide, hogy egységes legyen a kód. Képzeld el, hogy le van korlátozva a maximális behúzások száma mondjuk 10-re. Ez a 10, ha a te tabod 8 space, akkor már nagyon durván belóg, és nem fogod érteni, rinyálni fogsz a kevesebb behúzásért, míg ha csak 2, akkor teljesen normális.
----
India delenda est.
Hülye pelikán

Eh? Ha \t a policy, akkor tudom allitani, es ha tulsagosan kilog, akkor leveszem 8-rol kettore. Aki rinyal hogy tul nagy, annak meg adok egy Emacs manualt: vagy tanulni belole, vagy a fejere ejteni.

Megint technikai megoldast probalsz talalni a peldaval egy alapvetoen picit sem technikai problemara.

--
|8]

Látod, te is leírtad a lényeget. A space mindenkinél ugyanúgy néz ki, a tab meg nem. Az, hogy LEHETSÉGES megoldani a dolgot még nem változtat a tényen.
A tabnak persze más hátrányai is vannak, mindenképp buherálni kell a szövegszerkesztőket, hogy jól kezelődjön.
----
India delenda est.
Hülye pelikán

Igen, maskepp nez ki. Es ez miert is baj? Ha valakit zavar, be tudja allitani, hogy maskepp nezzen ki. Tab-nal ezt megteheti, spacenel nem (illetve de, csak sokkal nehezebben). Ez feature. Ha nem tudod kezelni, mert buta az editorod, vagy a kollegak, az nem a tab hibaja.

Mas szovegszerkesztokrol nem tudok nyilatkozni, de az enyemet semennyire sem kellet buheralni ahhoz, hogy jol kezelje a tabot. Ha tabot latott, tabot hasznalt, megjeleniteni akkoranak jelenitette, amit en mindezektol fuggetlenul beallitottam. Ha spacet latott, spacet hasznalt. Ennyi. Tobbet nem kell allitani rajta. Mivel en epp a default tab meretet reszesitem elonyben, egesz pontosan semmit nem allitottam a szerkesztomon.

Ugyanezen kodon dolgozo mas emberek hasonlokepp tettek, teljesen mas szerkesztojukben semmit nem allitottak azert, hogy megfeleloen mukodjon.

--
|8]

aha, viszont nem tudod elszamolni a space-eket, nem mindenki hasznal ide-t v vmi nagyobb tudasu editort.
egyebkent a forras is kisebb lesz, minek abba annyi space ?
foleg ha esetleg vmi kulso eszkozzel nezed meg, nem kell annyit ugralni a forrasban, azert egy tabon konnyebb vegiglepni.
a pep-ben a maximalis sorhossz 79, azt is betartod ?

Probléma akkor van, ha több fejlesztő több féle szerkesztőt használ és valamelyik megőrzi a tabulátorokat, valamelyik lecseréli és ha lecseréli, nem is feltétlen ugyan annyi szóközre teszi ezt. Ha csak szóközöket használsz, az mindenhol ugyan úgy néz ki és nem lehet elrontani.

Én azt gondolom, ha egy nyelv legnagyobb tervezési hibálya, hogy tab-ok helyett space-ket kell használjak, vagy zárójelek helyett indentálással kell struktúráljak, akkor boldogan szokok hozzá.
Egyébként, engem személy szerint ez egyáltalán nem zavar.
Vannak akik forradalminak tartják ezt a módszert, vannak akik ki nem állhatják. De nem hiszem, hogy valóban ilyen kardinális kérdés lenne ez :)

A legtobb "okorseg" a legtobb nyelvben olyan dolog, ami bizonyos extrem hataresetben adhat valami pluszt. Kb. mint a goto a legtobb nyelvben: szep meg jo meg minden, de csak nagyon modjaval.

De ennek csak es kizarolag hatranya van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( wachag | 2012. 12. 05., sze – 10:42 )

Egyik ismerősöm mérések adatainak feldolgozását végzi vele, tudtommal elég komoly projekt a dolog.

( bandy | 2012. 12. 05., sze – 10:43 )

OpenERP elég komoly project? Pythonban írodott...
más kérdés, hogy ebben nincs egyik sem, amit az új projektedre írtál :)

( uid_1406 | 2012. 12. 05., sze – 11:41 )

Irtam mar komplett nagyuzemi szamlazorendszer frameworkot wx/ncurses alapokon (10 eve hasznaljuk), grafikus feladatkezelot, multithread alairorendszert, jukeboxot, arcfelismerot,
forex analizatort/megjelenitot, ugyfelhivorendszert kijelzovel, grafikus szervermonitoring cuccot (szerverszoba ele kirakva), grafikus kepfeltolto klienst, stb...,
es ezek csak a nagyobb hangvetelu tobb 100/1000 soros cuccok.
Szerintem erdemes...

( develru | 2012. 12. 05., sze – 13:56 )

Köszönöm mindenkinek a hozzászólásokat. Igazából a "komolyabb" projekttel nem fogalmaztam pontosan. Valami olyasmit értettem alatta, hogy számításigényesebb és kritikusabb (a stabilitás fontos) szoftvereket is lehet-e pythonban írni.

Erre javarészt meg is kaptam a válaszokat, azért még mindig érdekelnek a személyes tapasztalatok. Nekem egyszerűbb lenne pythonban írni, így szerintem elkezdem, aztán meglátom mit kell C/C++-ban megírni. Majd a tapasztalatokról is beszámolok.
---
arch linux user

( hrgy84 | 2012. 12. 05., sze – 14:40 )

Egyik regebbi melohelyemen konkretan felhasznaloi feluleteket csinaltunk python/wxpython-ban. Celeszkozokre is, illetve usereknek is, komoly felhasznalasra. Szoval igen, lehet benne komoly projekteket csinalni.

Azt mar nem is merem pedzegetni, hogy a Citrix XenServer-ben egy csomo mindent valojaban Python hajt. Nem tudom, az eleg komoly projektnek szamit-e?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( Lacyc3 v | 2012. 12. 05., sze – 15:25 )

Kapcsolódó kérdés, mert látom itt sokan Pythonoznak elég komolyan: 2.7 vagy 3.x?

( zsoltt | 2012. 12. 05., sze – 17:44 )

Igen, pl. a google írt. A Google Drive desktop kliense ilyen. Ennek köszönhetően rettenetesen sok cpu -t eszik, és épp ezért sajnos nem is tudok előfizetni rá, pedig amúgy megfelelne a szolgáltatás.

( edaile | 2012. 12. 06., cs – 09:20 )

Simán.
Most egy olyan projekten dolgozom, ahol 30TB adatot (fájlok, db) kezelünk pythonnal. Nagyon fasza.

--
Ami elől menekülsz, az után szaladsz.

( develru | 2012. 12. 07., p – 10:23 )

Még érdekelne, ha már ennyien használják pythont nagyobb lélegzetvételű projektekre, akkor milyen IDE-t használtok?
---
arch linux user

Sokban függ attól, hogy hogyan, mire használod.
Ha csak szövegszerkesztésre, akkor a vim bőven elég.
Ha kódkiegészítésre is vágynál, akkor (azt hiszem) emacs az alap, attól fölfelé sok minden lehet.
Ha refactoring, integrált svn/git, projekt kezelés is kell, akkor csak az Eclipse-t ismerem. Netbeans python pluginje gázos volt, mikor próbáltam, mást meg nem láttam közelről.
(emacs tipikus példa rá, amivel nagyon szeretnék összeismerkedni, de minden alkalommal feladom néhány perc után, mert ellustultam, kényelmessé váltam)

( Refresh | 2012. 12. 07., p – 10:28 )

Ha nem gond, hogy picit offolok: mysql-t mivel szokás manapság használni, ha nincs keretrendszer? MySQLdb vagy a mysql.com-on ismertetett mysql.connector?

Köszi. Az Alchemy azért ágyúval verébre jelen esetben. Az egy ORM rendszer, nekem meg csak egészen "lightos" driverre van szükségem.

Azzal a másikkal, a mysql.connector-ral, találkoztál már?
Mert én ma botlottam bele először, miközben valami MySQLdb alternatívát keresgéltem win7 64bitre. A mysql.com-on találtam, ami azért meglepett...

(activestate pythonom van win7 64 bitre és az ingyeneshez nem engedi telepíteni a sajátját mysqldb csomagját :( )

Az SqlAlchemy két fő részből áll (ORM és Core). Ha nincs szükséged az ORM-ra, akkor is használhatod a Core részét, az is sok kényelmi szolgáltatást ad, szinte 0 overhead mellett.

A MySQL Connector/Python a legfiatalabb a sok MySQL DBAPI driver között, és egyben ez a hivatalos, Oracle által karbantartott cucc. Én egyiket sem használtam még, de ha kellene, valószínűleg ezzel próbálkoznék először.

( uid_6201 v | 2012. 12. 07., p – 13:48 )

Hangfelismerés, fotó analízis, jelfeldolgozás.

Ezekre a feladatokra a Python sebességi okokból csak úgy jó, hogy vele LEGÓzol össze egyébként C/C++ -ban írt jelfeldolgozó adatblokk-feldolgozó modulokat. Magát az elemi jelfeldolgozó algoritmust Pythonban nem célszerű írni, mert lassú lesz.

Példának lásd: GnuRadio projektet. C/C++ jelfeldolgozó algoritmusok Python segítségével "drótozva". Gyors és a Python miatt flexibilis.

Mérted a sebességet? Példának ajánlom figyelmedbe az alábbit:

1. generálj egy 100.000 sornyi 40 karakter hosszú [0-9A-Za-z] randomstringből álló fájlt.
2. olvasd fel, rendezd le 100-szor (ügyelve hogy mindig az eredetiről való kópiát rendezd) méghozzá az alábbi módokon:

a.) "LEGÓ nyelvként" használva a Pythont, azaz a C-ben írt beépített sort() metódussal dolgozz. Így a tisztán C-hez képest csak dupla erőforrás kell Python/Pypy esetén, hiszen a rabszolgamunkát a C-ben írt sort() végzi.
b.) "algoritmus nyelveként", azaz a QSORT-ot Python nyelven leprogramozva. Itt látványos lesz a különbség, a Pypy bíztató a Pythonhoz képest, de nem bíztató a C-hez képest. A cython a python kódban alkalmazott kényelmes listakezelés miatt elvérzik. Ha nem listákkal dolgozol a cython-nak szánt kódban (cdef-ekkel direkt C-s vektorok), akkor tudsz gyorsulást elérni.
c.) a fentieket vesd össze egy tisztán C-ben írt qsort futásidejével.

A time shell parancs segít időt mérni.

Ha a fenti teszteket elvégzed, rájössz, miért írtam, hogy jelfeldolgozás "algoritmus nyelveként" nem alkalmas, "LEGÓ nyelvének", azaz amikor az elemi blokkos műveleteket kötözöd össze, arra sok adat esetén is alkalmas.

LEGÓzva alkalmas erre is.
Lásd: általad mellékelt videó 3:29-nél a forráskódot, amit megtalálsz https://github.com/pablomouzo/pypy-image-demo

A sobel.py -ről beszélünk, benne egy érdekes sorral:

from io import mplayer, view
Ugyanitt az io.py -ben a LEGÓ

f = os.popen('mplayer -really-quiet -noframedrop ' + options +

Szóval nem mond ellent a google sem a python hasznosságának sem az előző hozzászólásomnak.
Lényeg, hogy a bitbirizgáló legalja műveletet valami C-ben írt modul vagy külső program végezze és minél inkább csak adatblokkonként dolgozzon vele a Python, ne bitszinten.

A python hasznossága a gyors módosíthatóságában rejlik, azaz hibrid megoldással dolgozva megfelelően gyors és mégis flexibilis lesz a program.

( zeller | 2012. 12. 07., p – 13:58 )

A Zorp és környékén is elég sok Python kód figyel, ha jól tévedek. Kisebb cumóból is van egy rakás - most épp Ganetivel, meg a Ganeti Webmanager-rel szórakozok, nagyrészt Python-ban vannak ezek is összelapátolva.

( saxus | 2012. 12. 09., v – 18:23 )

Bizonyos méret felett semmire nem használnék szkriptnyelvet.

Ahol teljesítmény kell, ott végkép nem. De ha nem akarsz C/C++-t, akkor még mindig lehet pl. C#-ban unsafe kódot használni, bár idő után úgy is előjön a CUDA/OpenCL.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kifelejtettem mégvalamit: és/vagy gyengén típusos nyelvet.

Hosszú távon, bizonyos méret felett több szívás van abból, ahol egyszerűsítenek ezek a nyelvek és sokszor arra megy el az idő, hogy ugyanazt elérjük, ami más nyelven alapvető.

Arról nem is beszélve, hogy pl. egy C# egy Java vagy akár egy C++ jobban el van látva toolokkal, libekkel, mint mondjuk egy random scriptnyelv. Teljesítményről meg akkor még nem is beszéltünk.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem tudnék most így hirtelen jól megfogalmazható szabályokat felállítani, hogy miért vagy miért ne. Eddigi tapasztalatok összessége az, hogy scriptnyelvek bizonyos méret felett - főleg ott, ahol már rákényszerülsz arra, hogy csupán a méretbeli nagyság miatt komolyabb, strukturáltabb architektúrát használj a szoftveredben - számomra nagyon az jön ki, hogy a scriptnyelvek többsége pont amiatt, mert lazábban kapcoslódnak egymással a dolgok, inkább hátráltatnak.

Konkrét példák:
- nagyon sok időt elvesz sokszor az, ahogy a paramétereket, ellenőrizni kell (már ha normálisan akarjuk csinálni). Mindezt úgy, hogy látom kontrasztként, hogy sokszor töredék kódból meg lehetne oldani egy típusos nyelvben, hiszen pl. ha egy csomó bejövő számot kell ellenőrizni, akkor úgy is kapok egy Exceptiont. Ezzel szemben a gyengén típusos nyelvekben nekem kell ellenőriznem, utána meg illene castolni és nem a különféle trükkös típuskonvertálásokra bízni a dolgot.
- Ez a típuskonvertálgatás PHP-nál különösen vicces tud lenni néha.
- Egy-egy refactoring iszonyú sok ideig tud tartani. Pont az elmúlt hetekben elégeltük meg kollégával a régi csontvázakat (ilyen 1..4 éves, nem használt régi dolgok) a kódban. Nekiálltunk takarítani és hát khm. lassú és fájdalmas munka végigkeresgélni az összes hivatkozást, ahelyett, hogy pl. nyomnék egy törlést az osztályra majd nyomnék egy buildot és szisztematikusan mennék végig az error listen.
- Jobb tooltámogatottság. Míg pl. scriptnyelveknél ott tartunk, hogy legyen már debugger meg auto complete, ami hellyel-közzel használható, addig más nyelveknél ez 10-20 éve nem téma, hogy van és kész. Ott már a refactoring a statikus kódanalizátorok, profilerek és sok-sok egyéb más hasznos dolognál tart az ipar. Debuggolás közbeni kódszerkesztésről (Java Hotswap, .NET/VS edit&continue) már ne is beszéljünk.
- Erre úgy is minden scriptnyelv fan úgy is azt fogja mondani, hogy "de a kóder volt a hülye" és igazuk is lenne, ha sokan nem a "mert xy-ban ez így egyszerű" érvet hoznák fel. Amikor kommunikálni kell valamivel, akkor időnként egyesek hajlamosak arra, hogy nem a szabványos megoldást használják, hanem 2-3 függvényhívásból összetákoljanak valami ahhoz hasonló, de szabványokkal végkép nem kompatibilis megoldást. Erre nagyon jó példa, a CSV, amit előszeretettel szeretnek egyesek explode+foreach+explode kombóval "feldolgozni", aztán hogy a ";" -al vagy az újsorral mi történik, az más kérdés.
- Sokszor nincs kész ajánlás arra, hogy hogyan is építse fel valaki a szoftverét, vagy mindenki megpróbálja újrafeltalálni az MVC-t (rosszul) vagy valami nagyon egyedit akar kitalálni és a végeredmény egy összekutyult karbantarthatatlan izé lesz. (Persze, tudom, lehet ezt másban is rosszul csinálni.)

És még sok-sok hasonló apróság, amely miatt egy idő után ahogy nő a projekt, úgy lesz egyre nehezebben karbantartható, debuggolható és egyre drágább a karbantartása.

Példának okáért van egy kb. 400-500K soros projekt, kb. négy és fél éve lettek lefektetve az alapjai. És ez úgy félmillió, hogy szerintem legalább 50-100K sor az idők folyamán már kikerült belőle, ahogy bizonyos részek fejlődtek vagy jöttek az új igények.

Ha most kellene kezdeni, valószínűleg Java vagy .NET lenne belőle. (Mielőtt valaki azzal jön, hogy jaj, de WS licenc kell hozzá: elenyésző tétel lenne.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Script nyelven is lehet korrektul strukturalt kodot irni, es Java/.NET-ben is lehet osszeganyolt, nehezen refaktoralhato szarkupacot osszerakni.

Volt mar szerencsem egy 10+ eves C++ kodhoz, millio folotti kodsorral, hat nem volt szep. Amikor reinterpret_cast hegyek, elbaszott templatek, kusza, logikatlan fuggosegek halmazat kell kibanyaszni egy olyan halmazbol aminek jelentos hanyada igazabol mar reges reg dead code, akkor teljesen mindegy, hogy miben lett irva.

Node arra akarok kilyukadni, hogy nem a nyelvvel van baj (neha azzal is, lasd PHP-s peldak, vagy a Python GIL) sok esetben, hanem azzal, hogy a koderek nem figyelnek oda, es a nyelv adta flexibilitast nem kihasznaljak, hanem visszaelnek vele.

--
|8]

"- Egy-egy refactoring iszonyú sok ideig tud tartani. Pont az elmúlt hetekben elégeltük meg kollégával a régi csontvázakat (ilyen 1..4 éves, nem használt régi dolgok) a kódban. Nekiálltunk takarítani és hát khm. lassú és fájdalmas munka végigkeresgélni az összes hivatkozást, ahelyett, hogy pl. nyomnék egy törlést az osztályra majd nyomnék egy buildot és szisztematikusan mennék végig az error listen."

Bocs, de ez a fejlesztoi kornyezet bune. En most refaktoraltam egy Ruby kodot, nem toltottem el tiz percet a dologgal, pedig arra a bizonyos osztalyra baromi sok minden hivatkozott. Mert volt egy jo IDE-m. Szoval, nagyon sok mulik az eszkozvalasztason is. Igaz, hogy ugyanezt a muveletet masfel evvel ezelott masfel ora alatt abszolvaltam volna - de nem ugyanezzel az eszkozzel. Az eszkozok fejlodnek, a karbantarthatatlan scriptnyelvbol az idok soran kezesbarany lesz. A Java/C# eszkozei se egyik pillanatrol a masikra pattantak ki Zeusz fejebol, volt olyan idoszak, amikor remalom volt debuggolni, refaktoralni, etc.

Amiket irsz: reszben egyetertek, reszben nem. Nagyon sok minden nem a scriptnyelvek bune, hanem a fejelsztoke. Java-ban is lehet ujrafeltalalni az MVC-t rosszul, vagy a standardokat nem koveto kodot irni. Es meg csak nem is kell erolkodni hozza. Ha labon akarod loni magadat, megteszed egy golyostollal is, nem biztos, hogy szukseged van ehhez lofegyverre.

Azt gondolom, hogy egy jo fejleszto akarmilyen nyelven kepes szabvanykoveto, letisztult es jol karbantarthato kodot irni, illetve egy rossz fejleszto minden nyelven, amihez csak nyul, kokanyolni fog. Igy szuletnek a megeroszakolt C++/C#/Java kodok. Az ilyenen egyszerre konnyu es nehez felulkerekedni: konnyu, mert altalaban a dontes az, hogy az ilyen fejlesztotol meg kell szabadulni, ha hosszu tavon nem valtoztat, es nehez, mert olyan munkat ro a csapatra, mely feleslegesen leterheli oket.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

En ezt ertem, de ha egy osztaly 15 perc, akkor 10 osztaly 150 perc, vagyis durvan masfel ora. Max. Ezzel szemben ha egy osztaly kitakaritasa mondjuk egy ora, akkor 10 osztalye tiz ora. Tehat egy jo IDE-vel sokkal gyorsabban lehet haladni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Haha, latszik, hogy nem csinaltal meg ilyet.

Nem linearis ugyanis az osszefugges a takaritas ideje es a kod merete kozott. A code cleanup tipikusan lassu folyamat, itt nem percekrol, hanem napokrol, hetekrol beszelunk 10.000 sor folott, ha a kod eleg szar.

Tartott mar nekem 20.000 soros legacy C kod clean-upja egy honapig. Aztan teljes ujrairas lett a vege, es a project kb. fel ev alatt futott ki.

Szoval nem a nyelv szamit, nem is az IDE, hanem a kodminoseg es a te tapasztalatod.

Ja, hat ugy igen. En mondjuk tobbnyire szerencsere olyan kodokba maszok bele melyebben, amiknel a kodminoseg nem annyira pocsek.

Mondjuk azert az IDE sokat tud szamitani. En pl. akarmennyire szerettem a NetBeans-t, tudtam azt, hogy a refaktoralo modulja bizonyos feladatoknal egyaltalan nem hatekony, tudtam, hogy a nem java fajlok kodkiegeszitesben nem szabad komolyabban megbizni, meg egy csomo ilyen hatranyt. Ugyanakkor az IntelliJ alapu cuccokban mindez tok maskepp van, mindketto sokkal jobb. Szoval azert szamit - ha nem is sokat, de legalabbis valamennyit.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Azt gondolom, hogy egy jo fejleszto akarmilyen nyelven kepes szabvanykoveto, letisztult es jol karbantarthato kodot irni, illetve egy rossz fejleszto minden nyelven, amihez csak nyul, kokanyolni fog."

Van egy koztes atmenet. Es eleg sok peldat lattam ra gyakorlatban is.
Egy fejleszto jol tud egy nyelvet, ismeri az ottani jol bevalt elfogadott kodolasi stilust, szokasokat, nyelv korlatait, best practice-it.
Most o kap egy masik nyelvet, hogy ebben kodolj wazze. Ha megprobalja, a megszokott szokasait egy teljesen mas jelegu nyelvre raeroltetni, abbol olvashatatlan, nehezen karbantarthato kod lesz.(, es panaszkodas forumokon :) )

"Az igazi programozó bármely nyelven tud FORTRAN programot irni" (FORTRAN lecserelheto barmire), az hogy tud egy dolog, de nem kene..

Python -ra valo "atnevelest" sem veletlenul szokas Python Philosophy -val kezdeni, aztan jol kifejteni.
python -c 'import this'

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ember, kepfeldolgozas volt az eredeti tema. Nehogy mar azt mond, hogy erre a python a legalkalmasabb nyelv. Masreszt tobbszor bebizonyitottak mar elottem, hogy pythont sokszor olyan feladatokra hasznaljak, amelyre messze nem ez a legalkalmasabb. Most linkeljem ide megint a KDE printer appletet?

Es nem minden formajat. Egy nehanyszor hasznalatos, parszaz soros szovegfeldolgozo script miatt en se fogok Eclipset vagy VS-t inditani, hanem megirom valami scriptynelvben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

...ellenben amikor eljutsz oda, hogy tobb core-ra (vagy meginkabb tobb processre, meg gepre) kene szetszorni a dolgot, akkor ott mondjuk C++-ben lekodolni nem egy leanyalom, de meg Javaban sem.

Amig egy processzen belul marad az ember, addig jok lehetnek az alacsony(abb) szintu nyelvek es megoldasok. Ha ezt kinovi a program, akkor viszont sok esetben tobb hatranyuk van, mint elonyuk. Persze egy hibrid megoldas akkor is lehetseges, csak merlegelni kell.

Vannak persze kesz megoldasok amik segitenek ilyen esetben, de az egy masik kerdes.

Mindenesetre az a kijelentes, hogy X meret felett szkript- es/vagy gyengen tipusos nyelv biztosan nem jo, butasag, szamos pelda van arra, hogy meretes project mukodik nagyon jol az altalad kevesbe alkalmasnak velt nyelven irva. Cserebe rengeteg pelda van arra is, hogy mennyire el lehet szurni C/C++/C#/stb-ben is.

Pelda kedveert, igaz, nem nagy project, de nemreg irtam at egy ~20k LoC C kodot Clojure-ra, mert single-thread mar keves volt, es a fene fog threadekkel szivni C-ben. Az eredmeny kb 2k LoC Clojure kod, ami tobb threaden tud futni szepen, tobbet tud, es egy threaden is elfogadhato teljesitmenyt hoz. Persze mindezt meg lehetett volna irni C-ben is, de az nem ment volna par nap alatt, es sokkal nehezebb lett volna fejleszteni, vagy epp debugolni. Egyszeruen nem erte meg a befektetest.

--
|8]

Ha a szamitasi teljesitmeny a fo szempont tobb szalra, akkor csak a C, esetleg C++ vagy assembly.

Ha nem recursive mutexel akkarsz syncronizalni, akkor java-ban kb. olyan bonyolult, mint C -ben.
volatile ill. memory barrier kerdes korenek finom hangolasa..

Persze ez a "20 ns faster TM" jatekai, egy adat tologato I/O -ra varo programnal nem jelentos.

Python:
http://docs.python.org/2/library/multiprocessing.html- talan ez legnagyobb teljesitmenyt ado cpython-os megoldas, java tol gyengebnek tunik, de eleg sok esetben nem ez lesz a bottleneck.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A fo szempont a teljesitmeny es a fejlesztesi ido kombinacioja, legalabbis szerintem.

Ez tobb esetben hibrid megoldast jelent, ahol a kritikus reszek C/asm, a tobbi meg ezeknel lenyegesen magasabb szintu nyelv. Ahol viszont a fejlesztesi ido, es a karbantarthatosag nagyobb hangsulyt kap, ott a C/asm reteg sokszor kiesik, mert megduplazni a geppark meretet olcsobb es gyorsabb, mint alacsony szinten lekodolni a gyorsabb kodot.

--
|8]

+1
"megduplazni a geppark meretet olcsobb es gyorsabb, mint alacsony szinten lekodolni a gyorsabb kodot."
Ez persze tényleg ritka eset. A sok duplázásban a végén olcsóbbra jön ki a C programozó. Ráadásul ha egy programrész nem jól párhuzamosítható, akkor főleg fontos, hogy az gyors legyen. Viszont jó tervezéssel megoldható, hogy már legyen egy működő program mire elkezdik az alacsonyabb szintű optimalizációt. A teljesítménykritikus részek meg általában pont rövidek és egyszerűek.

"...ellenben amikor eljutsz oda, hogy tobb core-ra (vagy meginkabb tobb processre, meg gepre) kene szetszorni a dolgot, akkor ott mondjuk C++-ben lekodolni nem egy leanyalom, de meg Javaban sem."

Ezt nem igazán értem. Ezek szerint jobb lenne (értsd könnyebb) Python-ban? Én python-ban még soha nem használtam több processzt, de C++-ban nem találom annyira bonyolultnak, és elég könnyű finomhangolni. Azt olvastam, hogy python-nak ez nem éppen erőssége.

---
arch linux user

Nem feltetlen pythonra gondoltam (ott sem leanyalom :P), mint erre celszeru nyelvre. De gondolj bele itt abba, hogy mivel jar egy feladat szetosztasa tobb szalra/programra. Nem csak abbol, hogy szetvagod, hanem abbol is, hogy skalazodni tudjon, ertelmesen. Na, ez a resze, a koordinacio, hogy melyik resz mit csinal es hogyan, mikor es milyen adatokra kell vigyazni, hogyan adjak at azokat a threadek egymasnak, az a szopas. (Tul sok lock megoli a teljesitmenyt, a tul sok masolas detto, stb)

Javaslom e temaban egyebkent Nathan Marz egyik eloadasat, ahol gyonyoruen szemleltetve van egy mostanaban egyre gyakoribb skalazodasi problema.

--
|8]

A 3D engine a legkisebb probléma :D Az igazi nyomort a több tízezer párhuzamosan bejelentkezett user okozza, mert a legtöbb MMORPG-vel ellentétben itt tényleg egy világban él mindenki. Még ha azok a világok külön szervere is fut(hat)nak. Nem tudom, hogy egy-egy rendszer tud-e már több szerveren lakni, a Jitának mindenképpen jót tenne, bár én már évek óta nem jártam arra.

Háttérinfó: http://www.slideshare.net/Arbow/stackless-python-in-eve#btnNext (ebből én mondjuk nem sokat értek :D)

Az általad linkelt slide-ok alapján szerver oldalon sem tiszta (stackless) python megoldás van egyébként, de mindegy, kicsit félrement ez a szál.
Eredetileg valami olyasmit akartam mondani, hogy: Biztos el jön az az idő is, amikor tisztán python-ban fognak igazán teljesítményigényes kódokat írni (mint pl. 3D engine játékhoz) *és* elfogadható lesz a hardverigénye, de az még nem a jelen. Találgatni lehetne persze, hogy 1-2-5-10 év kell-e még (a hardvernek), de ebben a topic-ban értelmetlen.

Azon merengtem el, hogy van-e így értelme a kérdésnek. Mert ugye egy tisztán C, C++ vagy bármilyen (magas szintű nyelvi) kód se kezeli közvetlenül a hardvert, hanem a driveren keresztül éri el(*). Esetleg egy független interfészen, pl. OpenGL-en át, bár fogalmam sincs, hogy ez a gyakorlatban hogyan működik. De a driver valószínűleg tartalmaz olyan részeket, amik nem az adott nyelven vannak implementálva, hanem akár assemblyben.

De a kártyán futó firmware is kérdéses, hogy az a hw része-e, avagy tekinthetjük szoftvernek? A szemléletes népi bölcsesség szerint a hardver az, amibe bele lehet rúgni, ez alapján viszont a firmware nem az.

Talán úgy lehetne megfogalmazni a kérdést, hogy az adott projekthez melyik az a magas (vagy legmagasabb) szintű nyelv, ami még elfogadható kompromisszumokkal használható. Pl. hogy írni kell hozzá egy modult (libet, bármit), ami a fürgeséget igénylő kódot implementálja, és a logika viszont az adott nyelven valósítható meg a legkényelmesebben.

Szerintem :D

*) bár anno még (már?) a pascalba is írtam inline assembly sorokat, de akkor az már nem tisztán pascal.

Igazad van ezzel kapcsolatban. De talán egy kicsit a kérdés hátteréröl: én munkámban napi szinten C/C++ban programozok. Kiterjesztésekhez használtunk python-t. Otthoni kisebb dolgokra python-t használtam. Automatizálás, táblázatok kezelése, statisztikák gyűjtése. Kedvelem python-t, mert gyorsan lehet benne dolgozni. De személy szerint nem érzem, hogy nagyobb (LoC) vagy számításigényesebb problémáknál lenne előnye, jogosultsága a tulajdonságainak (dynamic typing stb.). Meg ugye én nagyon ódzkodok attól, hogy futásidőben legyen valami interpretálva, de lehet ez csak a maradiságomnak tudható be. Ezért vagyok kíváncsi más véleményére is, hogy ti hogyan látjátok ezeket a problémákat. (kaptam is elég sok jó választ)

(Megj: annak idején szívtam Java-val, mert nem ez volt a megfelelő nyelv arra a feladatra - na de ez egy másik történet - , így azóta előtte inkább körülnézek.
---
arch linux user

( b | 2012. 12. 12., sze – 17:32 )

Személyes véleményem: felestdel. Képfeldolgozás általában úgy történik, hogy a kliens ad egy 640x480-as képet, hogy ezen kellene dolgozni. Aztán amikor használatba veszi a programot kérdezi miért lassú és/vagy fagy le, mondom küldje át a fájlt.... 100MB 65000x65000 ... rofl.
Mindegy is hangfeldolgozás és képfeldolgozás csak C-ben.

--
GPLv3-as hozzászólás.

( gthomas | 2012. 12. 13., cs – 21:06 )

Nem.

Nem azért, mert nem jó és szép és rugalmas, hanem mert gyakran TÚL rugalmas. A statikus ellenőrzések hiánya miatt később nagyon nehéz úgy hozzányúlni, hogy ne csak futásidőben derüljön ki, hogy valahol valami kimaradt.

Most éppen a Go-val (golang.org) ismerkedem, egyelőre szuper!

GT

Az a baj, hogy a go-bol hianyzik par kritikus dolog, ami kell a performance-hoz, pl. a pointer aritmetika lehetosege, illetve a memoria allokaciok ellenorzesenek a lehetosege.

Emiatt egyelore nem latom, hogy performance kritikus appnal miert valasztanak Go-t C++ helyett.

Lehet pl Go-ban custom memoria allocatort irni? Kerdezem attol, aki szakerto a temaban.

En a go-t eszeru kompromuszimnak tartom. Nem fogja megverni a C-t teljesitmenyben, nem fogja megverni python/perl/ruby/.. -t egyszeru hasznalhatosagban. Forditottan: egyszerubben hasznalhato a C -nel, sokkal tobbet nyujt tobb szalon ill. teljesitmentben, mint a legtobb script nyelv/interpreter/JIT.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hogyne lenne. Menj fel a webkit honlapjára, a fejlesztőire, és keress méréseket a custom allokátorok mennyit gyorsítottak (vagy épp lassítottak) az előző allokátorhoz képest. Ha eléggé visszamész, még biztos a gyári new-delete-hez képest is találsz statisztikát.
----
India delenda est.
Hülye pelikán

En mertem ilyet sokat sajat projectekben.
A valasz az, hogy fordito es platform fuggo.

Sokat dolgoztam DSP-kel, eleg szar allokatorokat adnak gyarilag a gyartok.
Ugye tudsz allokatort irni, aminel egy malloc konstans ideju O(1) muvelet. Csakhogy ez eszi a memoriat. Ha a programod memoriahasznalatat nem tudod elore, akkor a free() _tudtommal_ linearis ideju lesz konstans helyett, bar egynel kisebb szorzoval.

A gyari allokatorok ezeknel a szutyok rendszereknel csiga volt, raadasul O(n) vagy rosszabb.

Pointer aritmetika PC-en is szamit, pl. nagy tombok, kepek kezelesekor. Szarabb forditok eseten az sem mindegy, hogy [] vagy *, szerencsere manapsag mar ez nem tema, de meg emlekszek idokra, amikor az volt.

Anno mertunk C# agyonoptimalizalt es C++ nem optimalizalt sobel edge detektort. :) Vicces volt.

Tehát ha jól értem, az a gond, hogy a hagyományos malloc az elég lassú, ezért ezt valami trükkel
le lehet cserélni custom memory allocator-ra, ami valamilyen más algoritmussal foglalja a memóriát.
A kérdésem az lenne, hogy ha ilyen egyszerű a dolog, akkor alapértelmezettként miért nem ilyen memory
allocator van használva? Gondolom valami kiegészítő információt is kell tudni a rendszerről, hogy el tudjuk dönteni, hogy melyik memory allocator-t érdemes használni...

Az érdekelne, hogy a különbség igazából hol jött ki a sobel edge detectornál. Gondolom a C#-ban
is hasonló VM van, mint Java-ban, tehát a memória foglalás nagyon olcsó, tehát valószínűleg
nem ott lehetett a különbség...

Szerintem a modern operacios rendszerek rendszer allokatora eleg jo.
Azonban ahhoz, hogy egy malloc() es a free() is konstans ideju algoritmus legyen, megkotesek szuksegesek:
http://www.boost.org/doc/libs/1_51_0/libs/pool/doc/html/boost_pool/pool…

A pointerezes pedig akkor kell, ha nagy memoriateruletet jarsz be, pl. egy kepteruleten alkalmazol egy konvolucios filtert. Konkretan egy kepteruletes indexes bejarasa csiga a C/C++-hoz kepest. De C-en belul is van kulonbseg pl. a std::vector::operator[] es a pointeres [] kozott. Mondjuk ketszeres.

std::vector::operator[] es a pointeres [] kozott. Mondjuk ketszeres.

Nyilván, mivel a vector::operator[] az egy függvényhívás. De ha esetleg inline, ott akkor is van legalább egy index/tartomány ellenőrzés - és egy "goto" ami átugorja a kivételdobást :) - pluszban a sima pointeres eléréshez képest, ami - ha nem túl komplex a hivatkozás, akkor általában - egyetlen ASM utasítás.

Nem éppen új technológia (már 6 éves), de ennél sem konstans a free viszont ennek ellenére állítólag jó a teljesítménye.

Ennél szerintem rosszabb a helyzet. Release-ben az optimalizálónak ki kéne optimalizálnia az inline függvényhívásokat, mégsem teszi, ráaadásul nem is egy fv hívás van, legalábbis annál az std-nél, amit néztem.

Exception kezelés ki volt kapcsolva, index check úgyszintén, mégis lassabb volt. Egyszerűen az std implementáció túl komplex volt, és túljárt a fordító eszén... :)

Az operator[] egy függvény, amit minden valószínűség szerint kioptimalizál a fordító inline-ra, mivel ennyi a tartalma:
return m_belso_tarolo[i];

Semmiféle ellenőrzés nincs benne, az egyetlen ami miatt lassabb lehet az az, hogy dupla indirekció van: a this pointeren lévő pointeren lévő tömböt indexeled, nem közvetlenül egy pointeren lévőt.

Ezt mondjuk tisztességes fordítónak szintén ki kéne optimalizálnia, ha már inlineosított, és a paramétereket behelyettesíti. Ott van a stacken egy vector és annak egy adattagja egy pointer vs ott van a stacken egy pointer, nem látom mi a kettő között a különbség. Paraméterátadásnál lehet lassabb, mert a pointert lemásolod, de a vectort inkább nem.
----
India delenda est.
Hülye pelikán

Az operator[] egy függvény, amit minden valószínűség szerint kioptimalizál a fordító inline-ra, mivel ennyi a tartalma: return m_belso_tarolo[i];

Most megnéztem és tényleg. Gyermekkorom óta nem néztem meg az éppen aktuális implementációt, de én valamiért határozottan úgy emlékeztem, hogy itt van index ellenőrzés.

Vagy csak már keverem valamivel. Ez az átka annak, hogy egy egyszerű felhős alkalmazást nem lehet ma már megírni anélkül, hogy ne kelljen legalább 3-4 nyelvet felhasználni hozzá. :-/

Ez igaz. Én utoljára saját dinamikus két dimenziós tömb implementációnál használtam. Ott a függvény visszatérési értéke adta meg, hogy sikerült-e a művelet, így egy if elintézte a hibaellenőrzést és az érték beállítását else ág és a tömb aktuális méreteinek ismerete nélkül.

szerk. Ez egyébként C volt.

Lehet írni. Mostani verzió tcmalloc-ot használ.
https://groups.google.com/forum/#!msg/golang-nuts/bzFaGbmCVMs/Fn8Fdv3-K…

Nekem sokkal vonzóbb a Go-ban a Pythonhoz képest a sebesség, és a karbantarthatóság: ha kihasználom a Python dinamikusságából csak azt, hogy egy függvény többféle paraméterezéssel is hívható (milyen kényelmes!), akkor később már csak nehezen tudok hozzányúlni, mert nem tudom ki, hol, miért és milyen paraméterezéssel hívja - csak futásidőben derülnek ki a gondok.
Ezzel szemben a hibák nagy részét kidobja a fordíŧó a Go esetében.

GT

( uid_6201 v | 2012. 12. 16., v – 15:16 )

Köszönöm a témaindító felvetést. Mindig más és más módszert próbálok ki - készülvén a nagy adatmennyiségű projekteknél szükséges gyorsításra. Hogy miért python? Flexibilis, könnyen módosítható felső rétegként szeretem.

A natív C python modul írás megutáltatta magát, a cython nem hozta az általam várt gyorsulást. A pypy is "csak" a jó kategóriás (de jó!), azonban spéci feladatomhoz mindez nem elég gyors, de nem tudok a feladat jellege okán a pythontól magas szinten megválni.

Amivel most játszom és eddig bíztatónak tűnik: http://docs.python.org/3/library/ctypes.html

C-ben "normál" shared object elkészítése, majd

#!/usr/bin/env pypy

import ctypes

so = ctypes.CDLL("./pelda.so.1.0")
eredmeny = so.pelda_szamol(1000, 1100)

Azt hiszem, a nagy számítási erőforrást igénylő modulokra ez lesz a megoldásom. Egy nagyon gyors adatblokkot végigszámoló so fájl és egy pypy-vel elviselhető sebességű wrapper osztály, amely segítségével értelmesen lehet az adatblokkot átadni, átvenni felső szinten, majd flexibilisen tovább rendezni, elkészíteni az éppen szükséges kimutatásokat.

( THavoc v | 2012. 12. 17., h – 20:28 )

Irtam mar olyan python aplikaciot ami kb. 3 millio kozepesen komplikalt xml file-t dolgozott fel napi szinten + kb. 30 millio jpg-t es toltotte fel adatbazisba. Elso korben a beepitett xml lib bizonyult lassunak, de aztan talaltam olyat ameyik csak egy nagyon vekony layer a libxml2 folott. Mivel ez egy nagyon jol parhuzamosithato feladat, a GIL nem okozott problemat mert lazan lehetett processing-et hasznalni a threading helyett, volt vagy 5 sor kod. A cucc tobb darab quadcore/quadcpu szerveren futott, kimaxolva az osszes core-t. Ugyanezt a feladatot egy javas rendszer vegezte regebben, hat azt eleg durvan agyonverte ugyanazon a vason (1/4 ido alatt vegzett, bar a csere celja nem a sebesseg hanem a flexibilitas volt). Volt egy rovid fellangolas hogy nezzuk meg C++-ban ugyanazt, de par teszt-file feldolgozas utan kiderult hogy ugyanugy a libxml-ben van a CPU vegig, es alig par szazalekot lehet nyerni, tehat nem erdemes.

Tehat szerintem ha a python-t glue nyelvnek hasznalod mar letezo C libek folott, mindent meg lehet vele csinalni. Nagyon kenyelmes, modern nyelv, gyorsan lehet vele haladni, szoval szerintem +1.