[python] sockety - problem s HTTP spojenim

[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 veeeeeelmi 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 <PrikrylP na skil.cz>:
> 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
> > "\n"a 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 na py.cz
> http://www.py.cz/mailman/listi​​nfo/python
>


-- 
PS: prosim v mailoch tykat! nie vykat ;)

Tom na sQo
tomasnovella na gmail.com