[python] sockety - problem s HTTP spojenim

[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
> "\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 ;)