Re: [python] Jak na textový parser

2007-11-28 Tema obsahu Lukáš Linhart
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

2007-11-28 Tema obsahu Tomas Brabenec
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

2007-11-28 Tema obsahu Petr Prikryl
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

2007-11-28 Tema obsahu Tomy novella
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/listi​​nfo/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

2007-11-28 Tema obsahu Filip Štědrosnký
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

2007-11-28 Tema obsahu Jan Kundrát
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

2007-11-28 Tema obsahu Filip Štědrosnký
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

2007-11-28 Tema obsahu Jan Kundrát
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