Re: [python] Jak na textový parser
E-mail superman ze dne Wednesday 28 of November 2007: Tedy, pane kolego, snad to nebude v konferenci vadit, ale rád bych Vám vyseknul poklonu. Ten projekt je naprosto pěkně zdokumentován a i podle toho pdf je vidět, že jste nad tím hodně přemýšlel. Miloslav Ponkrác Dekuji dekuji, nicmene nemohu si to nechat pro sebe - prave proto, ze specielne na te pdf dokumentaci se podileli jini - http://projects.almad.net/czechtile/wiki/Contributors Jinak pokud by se zde nekomu chtelo to vyvijet, pripominkovat nebo pouzivat, at se ozve, lide ochotni obetovat cas jsou vzdycky vitani ,) -- Lukáš Linhart signature.asc Description: This is a digitally signed message part. ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] Jak na textový parser
Ja to delam jak jsi popisoval vyse, mam 20 reg. vyrazu a postupne je volam na pozadovany text. TB Martin Stiborský napsal(a): ok. Ve výsledku by měl fungovat tak, že hledá určité značky, které uzavírají ( většinou) text a místo těchto značek dosadí html značku. Z webu texy.info: //kurzíva// = i/i **tučné** = strong/strong Ale i jinak : Hlavní titulek = h1/h1 ** Podtitulek = h2/h2 a tak dále .. Mám pocit že na to momentálně nemám, už proto, že nemám ani jasno v tom, jak na to, ale o to víc si to beru jako výzvu a fakt rád bych to dal do kupy. Zkusím něco vykoumat z Texy zdrojáků, je to PHP, to bude taky sranda :D ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] sockety - problem s HTTP spojenim
Tomy novella -- c = atlantis_client() c.buffer = JEDEN PRIKAZ\r\n c.buffer = DRUHY PRIKAZ\r\n -- ... a odoslalo mi LEN tu druhu vec(v tomto pripade DRUHY PRIKAZ\r\n) preco? ako mam odoslat obe? Dvakrát za sebou se naplnil buffer, pokaždé něčím jiným. Asi se mezi tím musí provést nějaká akce, která obsah bufferu odešle. 2) (filozoficka): stale ked poslem po nejakom protokole prikaz, tak ma koncit \r\n? - totiz donedavna som novy riadok ukoncoval len \na stacilo to, preco je tak aj \r ved to je tabulator a ten predsa nevidno! :) aspon ja v tom nevidim logiku ;( Není to filosofická, ale technická otázka. Sekvence \r reprezentuje řídicí znak Carriage Return (návrat vozíku), posloupnost \n reprezentuje řídicí znak Line Feed (odřádkování). Oba řídicí znaky dostaly název v době, kdy vznikl klasický mechanický dálnopis. Znamenaly skutečně takto pojmenované mechanické akce. (Proto se taky řídícím znakům začalo říkat řídicí znaky.) V uvedeném pořadí se používaly proto, protože mechanická konstrukce dovolovala, aby se přechod na nový řádek (pootočení válce) prováděla i při pohybu vozíku na začátek. Pro zpětný pohyb vozíku tedy bylo dvakrát tolik času. Tolik tedy k postrádané logice. Postupem doby se sekvence označovaná také jako CR LF stala oddělovačem řádků v textových souborech, které už se na dálnopisnou stanici neodesílaly. V unixových systémech se vypustilo \r, u Mac je to myslím naopak. V DOSu a ve Windows zůstaly oba znaky. Aby se to programátorsky sjednotilo, zavedl se pojem otvírání souboru v textovém režimu, kdy se všechny možné koncové sekvence při načítání upravují na jediný znak \n a při zápisu se \n expanduje na příslušnou sekvenci, která se používá v daném OS. Pokud se ale soubor otvírá binárně, je nutné zapisovat všechny znaky koncové sekvence. Při odesílání přes buffer se typicky pracuje v binárním režimu. (Rýpnu si.) Unixoví programátoři otvírání souborů v textovém režimu často ignorují právě proto, že při otvírání v binárním režimu se vše v Unixu chová stejně, jako v textovém režimu. Díky tomu někteří na-Unix-hrdí jedinci vytvářejí špatně přenositelné zdrojové texty. Python až do verze 3.0 nedefinuje přísný datový typ řetězec (ne unicode). Do uvozovek zapisujeme posloupnost bajtů, i když nám je editor ukazuje jako písmenka. Ke konverzi jednoho znaku \n z řetězce na příadnou dvojici dochází až při zápisu do souboru otevřeného v textovém režimu -- a to jen v DOS/Windows. Nikdy jindy. pepr PS: prosim v mailoch tykat! nie vykat ;) P.S. Klidně mi v mailech vykej. Není to věc použitého média ;) ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] sockety - problem s HTTP spojenim
ahoj :) 1) no prave v tom, je ten pes zakopany, ze sa ma odoslat ten buffer, len co sa naplni, a neviem, ze aka ina akcia by sa mala vykonat ;( v dokumentacii k asyncore nieje nic take napisane ;( 2) diky veelmi pekne za krasne napisane vysvetlenie celej tej veci s riadiacimi znakmi ;) k tomu ps: napisal som to preto, lebo nemam rad, ked mi niekto vyka(mam to zo skoly, co mi od minuleho roku zacali novi ucitelia vykat, a ja nie a nie si na to zvyknut ;(( ) :) este raz diky za vysvetlenie :) 2007/11/28, Petr Prikryl [EMAIL PROTECTED]: Tomy novella -- c = atlantis_client() c.buffer = JEDEN PRIKAZ\r\n c.buffer = DRUHY PRIKAZ\r\n -- ... a odoslalo mi LEN tu druhu vec(v tomto pripade DRUHY PRIKAZ\r\n) preco? ako mam odoslat obe? Dvakrát za sebou se naplnil buffer, pokaždé něčím jiným. Asi se mezi tím musí provést nějaká akce, která obsah bufferu odešle. 2) (filozoficka): stale ked poslem po nejakom protokole prikaz, tak ma koncit \r\n? - totiz donedavna som novy riadok ukoncoval len \na stacilo to, preco je tak aj \r ved to je tabulator a ten predsa nevidno! :) aspon ja v tom nevidim logiku ;( Není to filosofická, ale technická otázka. Sekvence \r reprezentuje řídicí znak Carriage Return (návrat vozíku), posloupnost \n reprezentuje řídicí znak Line Feed (odřádkování). Oba řídicí znaky dostaly název v době, kdy vznikl klasický mechanický dálnopis. Znamenaly skutečně takto pojmenované mechanické akce. (Proto se taky řídícím znakům začalo říkat řídicí znaky.) V uvedeném pořadí se používaly proto, protože mechanická konstrukce dovolovala, aby se přechod na nový řádek (pootočení válce) prováděla i při pohybu vozíku na začátek. Pro zpětný pohyb vozíku tedy bylo dvakrát tolik času. Tolik tedy k postrádané logice. Postupem doby se sekvence označovaná také jako CR LF stala oddělovačem řádků v textových souborech, které už se na dálnopisnou stanici neodesílaly. V unixových systémech se vypustilo \r, u Mac je to myslím naopak. V DOSu a ve Windows zůstaly oba znaky. Aby se to programátorsky sjednotilo, zavedl se pojem otvírání souboru v textovém režimu, kdy se všechny možné koncové sekvence při načítání upravují na jediný znak \n a při zápisu se \n expanduje na příslušnou sekvenci, která se používá v daném OS. Pokud se ale soubor otvírá binárně, je nutné zapisovat všechny znaky koncové sekvence. Při odesílání přes buffer se typicky pracuje v binárním režimu. (Rýpnu si.) Unixoví programátoři otvírání souborů v textovém režimu často ignorují právě proto, že při otvírání v binárním režimu se vše v Unixu chová stejně, jako v textovém režimu. Díky tomu někteří na-Unix-hrdí jedinci vytvářejí špatně přenositelné zdrojové texty. Python až do verze 3.0 nedefinuje přísný datový typ řetězec (ne unicode). Do uvozovek zapisujeme posloupnost bajtů, i když nám je editor ukazuje jako písmenka. Ke konverzi jednoho znaku \n z řetězce na příadnou dvojici dochází až při zápisu do souboru otevřeného v textovém režimu -- a to jen v DOS/Windows. Nikdy jindy. pepr PS: prosim v mailoch tykat! nie vykat ;) P.S. Klidně mi v mailech vykej. Není to věc použitého média ;) ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python -- PS: prosim v mailoch tykat! nie vykat ;) [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] sockety - problem s HTTP spojenim
On St, lis 28, 2007 at 05:32:12 +0100, Tomy novella wrote: ahoj :) 1) no prave v tom, je ten pes zakopany, ze sa ma odoslat ten buffer, len co sa naplni, a neviem, ze aka ina akcia by sa mala vykonat ;( v dokumentacii k asyncore nieje nic take napisane ;( Zdravím Vzhledem k tomu, že se buffer odesílá jednou za čas a dle potřeby, tímhle jej jen naplníte a okamžitě přepíšete novými daty. Ale proč jej přepisovat. Prostě tam stačí data PŘIDAT. Tedy třeba: buffer=příkaz1\npříkaz2\n buffer+=příkaz3\n Konkrétní názvy proměnných se samozřejmě mohou lišit ale to už není tak podstatné, princip je, že v jednom stringu může být klidně i víc příkazů, proč taky ne ? -- regnarg -- Homepage: http://rg.pretel.cz -- JID: [EMAIL PROTECTED] V péči o štěstí druhých nacházíme své vlastní. -- Platón Čestná smrt je lepší než život v hanbě.-- Tacticus ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] sockety - problem s HTTP spojenim
Filip Štědrosnký wrote: buffer=příkaz1\npříkaz2\n buffer+=příkaz3\n Omlouvam se, ze si tuto hypotezu neoverim, ale neda mi nez reagovat. Tenhle pristup obecne neni thread-safe. Budeme predpokladat, ze operator += opravdu provede pouze hloupy append za konec stavajiciho stringu, a ze tedy buffer je opravdu obycejny string a ne nejaka specialni aio-specificka struktura, ktera si zamykani resi sama. Problemem je, ze append stringu zdaleka neni atomicka operace, teda takova, ktera kdyz jednou zacne, tak bez preruseni dobehne (coz mimojine je opravdu malo veci, i obycejne pricteni jednicky k intu neni atomicke). Muze klidne nastat situace, kdy operace += muze vyzadovat relokaci pameti, a potom se muze stat nasledujici: Hlavni thread: volam operator+=(). Hlavni thread: operator+=(): vidim, ze v bufferu uz neco je, a pridani dat si vyzada zvetseni pridelene pameti. Naalokuju tedy interne novy buffer a prekopiruju do nej stavajici data. Chystam se za konec pridat data nova, kdyz tu... Thread AIO se dostava ke slovu. Vidi data v bufferu, tak je precte, odstrani, odesle. Chysta se dale delat svou praci, kdyz tu ho planovac uspi a pusti ke slovu... Hlavni thread: ani nevi, ze byl prerusen. Takze placnu za svou kopii(!) puvodnich dat data nova a cely interni nove naalokovany buffer priradim do promenne buffer, ktera se vsak mezitim vyprazdnila. Ja o tom ale vubec nevim. Vysledek: V bufferu jsou stara data, ktera tam nemaji co delat. Hezky vecer a pouzivejte zamykani, pripadne vhodnejsi datove struktury, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] sockety - problem s HTTP spojenim
On Wed, Nov 28, 2007 at 08:08:11PM +0100, Jan Kundr�t wrote: Filip Štědrosnký wrote: buffer=příkaz1\npříkaz2\n buffer+=příkaz3\n Omlouvam se, ze si tuto hypotezu neoverim, ale neda mi nez reagovat. Tenhle pristup obecne neni thread-safe. Budeme predpokladat, ze operator += opravdu provede pouze hloupy append za konec stavajiciho stringu, a ze tedy buffer je opravdu obycejny string a ne nejaka specialni aio-specificka struktura, ktera si zamykani resi sama. Problemem je, ze append stringu zdaleka neni atomicka operace, teda takova, ktera kdyz jednou zacne, tak bez preruseni dobehne (coz mimojine je opravdu malo veci, i obycejne pricteni jednicky k intu neni atomicke). Muze klidne nastat situace, kdy operace += muze vyzadovat relokaci pameti, a potom se muze stat nasledujici: Hlavni thread: volam operator+=(). Hlavni thread: operator+=(): vidim, ze v bufferu uz neco je, a pridani dat si vyzada zvetseni pridelene pameti. Naalokuju tedy interne novy buffer a prekopiruju do nej stavajici data. Chystam se za konec pridat data nova, kdyz tu... Thread AIO se dostava ke slovu. Vidi data v bufferu, tak je precte, odstrani, odesle. Chysta se dale delat svou praci, kdyz tu ho planovac uspi a pusti ke slovu... Hlavni thread: ani nevi, ze byl prerusen. Takze placnu za svou kopii(!) puvodnich dat data nova a cely interni nove naalokovany buffer priradim do promenne buffer, ktera se vsak mezitim vyprazdnila. Ja o tom ale vubec nevim. Vysledek: V bufferu jsou stara data, ktera tam nemaji co delat. Hezky vecer a pouzivejte zamykani, pripadne vhodnejsi datove struktury, Zdravím a omlouvám se za další narušení hypotézy, ale: 1) myslel jsem, že se nejedná o threaded aplikaci ale asyncore/asynchat, alespoň jsem to tak z kontextu pochopil 2) stringy jsou neměnitelné, takže to není append, ve skutečnosti se spojí, vytvoří se nový string a ten se teprve přiřadí, to už atomická operace je 3) vzhledem k pythonímu GIL je vše (mnohdy až příliš) thread-safe a pokud nepoužíváte nějaké neobvyklé C extenze, nemusíte zamykat skoro nic -- regnarg -- Homepage: http://rg.pretel.cz -- JID: [EMAIL PROTECTED] V péči o štěstí druhých nacházíme své vlastní. -- Platón Čestná smrt je lepší než život v hanbě.-- Tacticus ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] sockety - problem s HTTP spojenim
Filip Štědrosnký wrote: 1) myslel jsem, že se nejedná o threaded aplikaci ale asyncore/asynchat, alespoň jsem to tak z kontextu pochopil Aha, ja jsem tak nejak predpokladal, ze asyncore.loop() pobezi ve svem threadu, pardon. 2) stringy jsou neměnitelné, takže to není append, ve skutečnosti se spojí, vytvoří se nový string a ten se teprve přiřadí, to už atomická operace je No, mohl bych poprosit o referenci na nejaky zdroj, ktery tvrdi, ze od zacatku provadeni vyrazu buffer += foo az po jeho dokonceni se nedostane ke slovu jiny thread? Problemem v dane situaci je prave moznost prepnuti do jineho threadu mezi spojenim stringu a prirazenim do promenne. Netvrdim, ze to shodi interpret, ale ze v promenne buffer mohou byt necekana data. Vzhledem k tomu, ze se celkem bezne [1] tvrdi, ze += 1 na int *neni* atomicke, tak soudim, ze append na (immutable) stringy rovnez nebude. 3) vzhledem k pythonímu GIL je vše (mnohdy až příliš) thread-safe a pokud nepoužíváte nějaké neobvyklé C extenze, nemusíte zamykat skoro nic Silne nesouhlasim, viz znovu [1]. Dalsi vygoogleny odkaz je thread [2]. [1] http://effbot.org/zone/thread-synchronization.htm [2] http://mail.python.org/pipermail/python-list/2000-April/030896.html Hezky vecer, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
