python gondolatok

dev Comments Off
Oct 202011

Pár beszélgetés miatt újra elgondolkoztam azon miért tetszik a python, és arra jutottam, hogy valójában nem is annyira az ilyen-olyan szintaktikai vagy valami felületi tulajdonságai tetszenek, hanem leginkább az, hogy gyakran arra ösztönöz, hogy absztraktabb és kezelhetőbb kódot írjak – anélkül, hogy akármilyen paradigmát is explicit módon rám erőltetne.

Például sokszor már alapból listákba rendezek adatokat, amiket  már könnyű iterálni pythonban, másrészt gyakorlatban is látom, hogy milyen könnyű prototípus kódot írni, ha odafigyelsz 1-2 dologra. Az utóbbi pár prototípus függvényemben szó szerint elég volt csak (a már előre is látható)  konstansokat paraméterekre cserélnem, hogy más module-okba importálható függvényeket kapjak.

Persze nem lesz azért lisp-absztrakt, de ezek  - kiegészítve a speciális eljárásnevekkel, amikkel, mint valami custom interface-szel könnyen tudsz saját osztályt a python nyelvi stílusához igazítani  - olyan dolgok, amik más nyelvben való programozáskor is segítenek azzal, hogy más szemszögből világítanak meg egy adott problémát.

Tagged with:

web serving

dev Comments Off
Oct 022011

Az előző bejegyzés kissé félrevezető lehetett, mert igazából a legtöbb cherrypy-s problémám nem abból adódik, hogy ezt vagy azt mennyire lehet megcsinálni, hanem hogy a dokumentációjukban elég nehezen találom meg az infót.

Mindemellett most már eljutottam oda, hogy az eddigi, a különböző bejegyzésekben említett kisebb programok egybefűzve, webservice-ként üzemelhetnek tovább, kezdve a bejövő adatok beolvasásától egészen egy AJAX-os felületig egy belső hálózaton. Azért mégis csak haladtam valamennyit. :)

A matplotlib-nek amúgy elég meredek az import ideje, a cherrypy-t is üti pl., de service-ként futva a cherrypy-vel együtt ez csak indulásnál jelent plusz időt. Csak elgondolkoztató, hogy mennyi mindent használhat (pl. tk?) miközben relatíve egyszerűbb dolgokra kell csak, egy sima outputtal.

Mindenesetre most működik a dolog – igaz, még mindig csak alpha – úgyhogy következőnek a lekérdezést bővítem ki, és utána jöhet a többi feature. :)

Tagged with: , , , ,

webpdf

dev Comments Off
Sep 172011

Az utóbbi időben nem sok új dolgot néztem dev téren. Inkább azzal foglalkozok most, hogy az eddig megnézett részeket egységes keretbe foglaljam végre, és az első lépéseket meg is tettem ez irányba a cherrypy és a reportlab segítségével. Természetesen nem volt nagy erőfeszítés, mivel a megfelelően függvényekbe szedett dolgokat könnyű kívülről hívni, csak paraméterezned kell 1-2 kezdeti értéket. A cherrypy pedig elég python barát ilyen téren, mert kb. tényleg csak a return részeket kell jól megírnod, és szinte olyan így, mint amikor egy standard print-tel írnál cgi-t.

A másik lehetőség, amit használtam én is, hogy a cherrypy-s függvényeket iterátorként írod meg yield-del, és habár ez még mindig nem ugyanaz, mint egy sok print-es megoldás, egy megfelelően megszerkesztett template függvény segítségével áttekinthető marad az egész, és a sima cgi-hez képest lesz kb. +1 logikai szint.

Összességében egyszerű volt egy directory list-ből különbözően paraméterezett linkeket generálni, amik aztán a pdf generátoromat hívták ezen paraméterekkel, és utána csak a megfelelő helyre írtam a pdf-eket. Az egyetlen bökkenő az volt a végén, hogy egy standard redirect-tel akartam ezt visszaadni a kliens felé, de localhost-hoz máshogyan kell az url-t szerkeszteni, mint egy nem local domainhez. De most már remélem egy serveren fogom folytatni majd.

Tagged with: , , , ,

graphs

dev Comments Off
Aug 272011

Remélem sikerül majd az összes dolgot, amit megnézek egy felület alá hoznom, mindenesetre a munkahelyi adatok feldolgozásához eszembe jutott, hogy jó lenne keresni valamiféle grafikon lib-et is.

Érdekes módon az a reportlab is tartalmaz ilyen egyszerű ábrákhoz eszközöket, amit végül pdf generálásra is használtam pythonból. Nagyon jó lib amúgy, csak kicsit túl nagy, szóval nem 1-2 sor amíg generálsz valamit, de nagyon sok mindent lehet benne és elég profi.

A másik alternatíva pdf-től függetlenül a matptlotlib, ami valami olyasminek néz ki, amivel Zoli generálná a grafikonjait… :) Na jó, igazából ezt nem tudom, de egy normális graph lib-nek néz ki, többféle módon menthető grafikonokkal, szóval valószínű valamilyen ezzel előállított bitmap outputot fogok a kiszolgált weblapokba integrálni.

Viszont egy régi p4-esen olyan lassú az import – legalábbis gondolom, hogy az import – hogy gondolkozom azon, hogy külön localhoston futó service-ként fusson-e ez a grafikon generáló progi, párhuzamosan a majdani webservice-szel. Majd elválik.

Tagged with: , , ,

régi progi

dev Comments Off
Aug 172011

Amikor bent melóhelyen dolgoztam, visszakerestem valami miatt az évekkel ezelőtt írt programom kódjában valamit, és eléggé rácsodálkoztam, hogy hogyan van megírva. :) Jó, akkor tanultam még csak a pythont, de pl. csomó dolog úgy néz ki, hogy elég feleslegesen szerepel függvényként.

Persze ok, hogy a megfelelő függvényneveket használva a main()-ben jól olvasható lesz a logika, de azért most már nem hiszem, hogy csak ilyen megfontolásból ennyire funkcionális programozást használnék… főleg úgy, hogy ezek a függvények néha annyira speciális paramétereket kérnek, hogy nem is lehet nagyon ezen a programon kívülről hívni őket.

Mindettől függetlenül évek óta használom is folyamatosan ezt a programot, szóval egyáltalán nem arról van szó, hogy hú-de-használhatatlan, csak épp amíg régen ezt egy hónap alatt írtam meg ha jól emlékszem, most egy hónap alatt tanultam – és utána használtam – sqlite-ot, feldolgoztam vagy 3 file formátumot (nem pedig 1-et), és kerestem webservert.

Most pedig majd neki állok relax ng-t tanulni, de mindezt csak azért mondom, mert úgy látszik ez a programozás is valóban egy ilyen gyakorlati dolog – és az igazat megvallva úgy érzem, hogy az elmúlt hónapban nem is haladtam annyira, mint ahogy szerettem volna. :)

Tagged with:

cherrypy

dev Comments Off
Aug 092011

Az eddigi webserver keresgélés a munkahelyi alkalmazásomhoz most egy időre befejeződik, és az nginx-re sem lesz szükségem még, mert a cherrypy nevű python module/webserver csomó mindent tud, amivel egyelőre tovább haladhatok, és önmagában vagy robusztusabb webserverrel együtt is működik.

Ezért szeretem amúgy az ilyen nyelveket, mert könnyen lehet új ötleteket megfogalmazni bennük – több mindent kipróbálni azért, hogy lásd, neked melyik a legmegfelelőbb épp. Másrészt a cherrypy-féle hello world (ld. az oldalukon) szerintem jól mutatja, hogy lehet objektum-orientált kódot eredetien használni. :)

Tagged with: , ,

sqlite #2

dev Comments Off
Jul 312011

Hogy a munkámról is írjak annak, akit érdekel, per pillanat azon gondolkozom, hogy az sqlite adatbázis adatait milyen arányban kéne python-ban illetve sql-ben bűvészkedni. Nevezetesen hogy inkább sql scriptet generáljak, és azt futtassam le az adatbázison, vagy inkább csak kellő mennyiségű select utasítással kérjem le az adatokat, és utána pythonnal végezzem el az egyéb szükségem műveleteket.

De ez inkább gyakorlati probléma számomra, hiszen amit lehet, valószínű hasznosabb sql scriptként megírni, viszont a későbbiekben webes felületet kell írnom ehhez, és úgy érzem python objecteket könnyebben fogok tudni interface-elni, mint közvetve sql struktúrákat. :)

Tagged with: ,

chartest 2 #2

dev Comments Off
Jul 312011

Tovább dolgoztam a lentebb említett chartest progin – a screenshot most is ugyanaz lenne. :) Tovább gondoltam, hogyan működjön a kamera, mert az ok, hogy eddig is követte a karaktert, de a pályának nem voltak határai, hanem csak végtelenül ismétlődött. (Tudom, erről is kellett volna shot, de sry, szerintem ez az egész nem egy nagy szám. :))

Most már normálisan megáll a kamera a széleken, és a karakter kamerától függetlenül is fel tudja fedezni a pálya szélét – tehát nem mindig van a kamera közepén – persze mindezt úgy csinálom, hogy a 2D kamerát tetszőleges későbbi objektumra is rá lehet majd állítani.

Sajnos az a bizonyos hiba még mindig fennáll, egészen valószínű, hogy valami scheduling hiba lesz, – tehát a frame-enkénti update-et érintő – durván 1 másodpercenként megakad egy pillanatra, érezhetően. Nehéz valami ilyet debugolni, amikor a cpu használat úgy közel 0%, és azt is nehéz elképzelni, hogy egy 2d render megterhelje a vga-t, amikor mostani játékok… hát mennek. ;)

Tagged with:

debug

dev Comments Off
Jul 242011

Tegnap egész nap újfent karakter kódolásokkal vacakoltam python 2-ben, mert mint említettem a pdf reader részben volt egy nem triviális hack, amiről azt hittem, hogy problémát okoz. Hát a hack az valóban hack volt, de nem okozott problémát. :)

Először is a pdf nem adatcserére való. Ez persze mindenki számára nyilvánvaló, aki kicsit is ért a dolgokhoz… mennyivel egyszerűbb lenne, ha xml-ből kéne xml-t csinálnom. :) Na de ezt küldik, ezzel kell kezdeni valamit, és amúgy is, azt hiszem ami xml-t küld az oep, annak is iso-8859-2 a kódolása! Nem utf-8 – abszurd lenne! – és még csak nem is windows-1250! :)

Szóval a tegnapi napom azzal ment el kb., hogy próbáltam megtalálni a hiba okát, – extra szóközök az adatfolyamban – és ezért átnéztem a python 2 és 3 dokumentációját, néztem egyszerű pdf 1.3 syntaxt, számtalan debug print-et csináltam a programból, mire rájöttem a következőkre:

  1. Windows alatt a c-python alapból 16bites unicode-ba kódol, linux alatt 32bites belső kódolás a default.
  2. A pdf syntax-ot olvasva kiderült, hogy kb. úgy működik, ahogy gondoltam, és a kód, ahogy átírtam a readert olyan, amilyennek lennie kell.
  3. És így az extra karakterek nem szóközök, hanem null karakterek az adott unicode környezet byte-számától függően.
  4. Szóval a hacket kitöröltem, minden létező string-et átírtam pythonban unicode stringre – bár ezt inkább csak a következetesség kedvéért – és próbáltam keresni egy karakter encodert, ami normálisan olvassa az adatot unicode-ból.
  5. De valójában a kódolás is mindegy, hiszen ha bármit is írok, az a python ‘belső magánügye’, hogy hány biten tárolja, szóval nekem nem kéne látnom annyi extra null karakter, amit látok.
  6. Tehát valahol mégis csak van egy alap ascii konverzió valamelyik függvénynél, amit használok, (ami megpróbálja 8-bites stringként kezelni a több bites unicode byte stream-et,) annak ellenére, hogy már minden stringem unicode string.
  7. Szóval próbáltam átírni 1-2 függvényt saját implementációra, és amikor olvastam a dokumentációt, akkor láttam, hogy valóban, az egyik module (StringIO) c implementációja nem támogatja a unicode-ot, csak a python implementáció.

Szóval kitöröltem minden debug szemetet meg a hack-et is… kitöröltem a kódból EGY karaktert, és minden szép és jó azóta. True story.

Aztán hogy a munkahelyi környezetben mi lesz, az egy más kérdés, de ha rajtam múlik persze mindenhol unicode/utf-8. :) Mindenesetre poén, hogy nem eldobja a unicode inputot az ezt nem támogató class… hanem itt-ott tök más helyeken látsz unicode meg ascii errort. A programozás szépségei – még jó, hogy szeretem csinálni. :)

Tagged with: , ,

sqlite

dev Comments Off
Jul 212011

Egy újabb lépéssel közelebb került már a proof-of-concept prototípus, merthogy az eddig kinyert adatokat némi szintaxis tanulás után egyszerű volt sqlite-ba fésülni. (Aki nem tudná, ez kb. egy 1 file-os sql adatbázis.) A további sql gondokat valószínűleg leginkább a unicode karakter kezelés fogja jelenteni, de ez már nem nagy probléma.

Egyfajta ellenőrzésként még meg próbálok befésülni egy másik, már félig elkészült programból adatokat, hogy összevessem mindet – és ha ez elkészül, akkor effektíve amióta ezeket a pdf-eket kapja a kórház, a bennük lévő adatok bármilyen időközre és összefüggésben lekérdezhetőek lesznek… csak az sql-en kívül is valami felületet kéne eszkábálni hozzájuk. :)

Amúgy a lekérdezés meglepően gyors, ha valami miatt szükségét érzem majd a webes felület és az adatbázis közötti kapcsolat korlátozásának, az inkább lesz a hálózati sávszélesség, semmint a lekérdezés sebessége miatti aggodalom.

Tagged with:
Older Entries
© 2011 zero or more Suffusion theme by Sayontan Sinha