Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > cz.comp.lang.python > #3037 > unrolled thread

Re: [python] Roboti, REST, Flask?

Back to article view | Back to cz.comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [python] Roboti, REST, Flask? Marek Nožka <marek@tlapicka.net> - 2015-09-11 15:56 +0200
    Re: [python] Roboti, REST, Flask? Pavel Schön <pavel@schon.cz> - 2015-09-29 06:30 -0700
      Re: [python] Roboti, REST, Flask? Honza Král <honza.kral@gmail.com> - 2015-09-29 15:48 +0200
      Re: [python] Roboti, REST, Flask? Pavel Schön <pavel@schon.cz> - 2015-09-29 07:28 -0700
        Re: [python] Roboti, REST, Flask? Honza Král <honza.kral@gmail.com> - 2015-09-29 18:31 +0200
          Re: [python] Roboti, REST, Flask? Pavel Schön <pavel@schon.cz> - 2015-09-29 11:09 -0700

#3037 — Re: [python] Roboti, REST, Flask?

On Fri, 11 Sep 2015 14:29:36 +0200 Hynek Fabian
<hynek.fabian@firma.seznam.cz> wrote to Konference PyCZ <python@py.cz>:

> Ja jsem asi moc ovlivnenej corewars, ale nejak mi unika k cemu by tam
> sitova komunikace byla. Stacilo by kdyby klienti uploadnuli modul,
> simulator si vsechny naimporti, projede a vyhodi vysledek (vitezove,
> resp. zaznam tahu). Na to staci blbej sitovej share.

Pravidla mám zatím vymyšlená velice jednoduchá, ale budou se časem
zesložiťovat. Jednotlivý roboti na sebe budou reagovat, bude se měnit počet
hráčů atd.

Marek

-- 
 @ @ @	   Marek Nožka
 '****.@
 :*****`@   email: marek <@t> tlapicka <d.t> net
 `*****'   jabber: tlapicka <@t> mitranet <d.t> cz
  :****:      web: http://tlapicka.net/
  `****'
  `****'   Powered by Debian GNU/Linux
  `.**'
    ¨¨

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [next] | [standalone]

#3039

Ahoj,

dovolim si navrhnout pure python reseni na strane serveru zalozene na threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:

http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/

Ve zkratce:

- na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
- na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace importne a vola podle potreby.

Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.

[toc] | [prev] | [next] | [standalone]

#3040

Psal jsem to tehdy, pisu to i ted - tohle reseni je naprosto nevhodne,
nema zadne reseni konkurentniho pristupu. Neni thread safe napriklad,
coz ho naprosto diskvalifikuje jako implementace zamku. Nehlede na to,
ze je to reimplementace kola.
Honza Král
E-Mail: honza.kral@gmail.com
Phone:  +420 606 678585


2015-09-29 15:30 GMT+02:00 Pavel Schön <pavel@schon.cz>:
> Ahoj,
>
> dovolim si navrhnout pure python reseni na strane serveru zalozene na threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>
> Ve zkratce:
>
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace importne a vola podle potreby.
>
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> _______________________________________________
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#3041

Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro studijni a vyukove ucely, pokud se nepletu.

Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast neresi vypadky spojeni, neimplementuje reconnect apod. Pokud nastane chyba v TCP, na strane klienta se vyhodi vyjimka socket.error a je jen na nem, jak se zachova. 

Knihovna take neresi deadlock, ale to ani normalni threading neresi deadlocky. Jejich predchazeni je uz mimo ramec teto diskuze.

BTW, nad jednoduchym lockem lze stavet vyssi primitiva, semafory apod.


Dne úterý 29. září 2015 15:51:15 UTC+2 Petr Messner napsal(a):
> Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav zámků zachován? Co se stane, když klient požádá o acquire a musí čekat, protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť, spojení se ukončí a recv() vrátí prázdný řetězec?
> 
> 
> Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis (http://antirez.com/news/77) Apache Zookeeper, Apache Helix...
> 
> 
> Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do "normálního" algoritmu stačilo přidat sokety.
> 
> 
> PM
> 
> 
> Dne 29. září 2015 15:30 Pavel Schön <pa...@schon.cz> napsal(a):
> Ahoj,
> 
> 
> 
> dovolim si navrhnout pure python reseni na strane serveru zalozene na threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
> 
> 
> 
> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
> 
> 
> 
> Ve zkratce:
> 
> 
> 
> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
> 
> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace importne a vola podle potreby.
> 
> 
> 
> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
> 
> 
> 
> _______________________________________________
> 
> Python mailing list
> 
> pyt...@py.cz
> 
> http://www.py.cz/mailman/listinfo/python
> 
> 
> 
> Visit: http://www.py.cz

[toc] | [prev] | [next] | [standalone]

#3042

2015-09-29 16:28 GMT+02:00 Pavel Schön <pavel@schon.cz>:
> Moje knihovna nikdy nebyla nasazena v produkci, je to ciste experimentalni zalezitost, hricka pro studijni ucely. Autor puvodniho dotazu hleda neco pro studijni a vyukove ucely, pokud se nepletu.

Obzvlast pro vyukove ucely je skutecne vhodne vybrat dobra reseni, v
tomto pripade tedy neco ze std knihovny nebo neco co funguje a plni
sliby

Nejhorsi co se muze stat je, ze se nekdo nauci spatne postupy a
principy, proto je vzdy dulezite, obcas i za cenu komplexity (django
vs flask) nebo extra zavislosti (gunicorn nebo twisted na normalni
server vs custom tcp socket), zvolit reseni ktere podporuje dobre
navyky. V tomhle pripade je dobry navyk i nevynalezat kolo.

> Server si v zadnem pripade nepamatuje stav zamku pri restartu, klientska cast neresi vypadky spojeni, neimplementuje reconnect apod. Pokud nastane chyba v TCP, na strane klienta se vyhodi vyjimka socket.error a je jen na nem, jak se zachova.
>
> Knihovna take neresi deadlock, ale to ani normalni threading neresi deadlocky. Jejich predchazeni je uz mimo ramec teto diskuze.
>
> BTW, nad jednoduchym lockem lze stavet vyssi primitiva, semafory apod.
>
>
> Dne úterý 29. září 2015 15:51:15 UTC+2 Petr Messner napsal(a):
>> Zajímavý kus kódu. Co se stane, když se server restartuje, zůstane stav zámků zachován? Co se stane, když klient požádá o acquire a musí čekat, protože zámek má již někdo jiný, ale zrovna v tu chvíli vypadne síť, spojení se ukončí a recv() vrátí prázdný řetězec?
>>
>>
>> Když už řešit zamykání takhle síťově, tak aspoň pořádně :) Viz např. Redis (http://antirez.com/news/77) Apache Zookeeper, Apache Helix...
>>
>>
>> Bohužel, distribuované algoritmy nejsou tak jednoduché, že by do "normálního" algoritmu stačilo přidat sokety.
>>
>>
>> PM
>>
>>
>> Dne 29. září 2015 15:30 Pavel Schön <pa...@schon.cz> napsal(a):
>> Ahoj,
>>
>>
>>
>> dovolim si navrhnout pure python reseni na strane serveru zalozene na threadingu a lockach. Kdysi jsem napsal jednoduchy lock manager. Viz:
>>
>>
>>
>> http://code.activestate.com/recipes/578194-distributed-lock-manager-for-python/
>>
>>
>>
>> Ve zkratce:
>>
>>
>>
>> - na serveru bezi TCP daemon (./dlm.py), ktery obsluhuje klienty.
>>
>> - na klienty umistis tentyz soubor dlm.py, ktery si klientska aplikace importne a vola podle potreby.
>>
>>
>>
>> Aplikace potom funguje velmi podobne, jako bys programoval s mutexy.
>>
>>
>>
>> _______________________________________________
>>
>> Python mailing list
>>
>> pyt...@py.cz
>>
>> http://www.py.cz/mailman/listinfo/python
>>
>>
>>
>> Visit: http://www.py.cz
>
> _______________________________________________
> Python mailing list
> python@py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#3043

V tom se asi neshodneme. Nespatřuji nic špatného na tom napsat si vlastní TCP protokol založený na socketu z stdlib.

Zastávám názor, že je dobré rozumět a učit se věci pěkně odspodu. Ono i to Django nebo Flask takto vznikl. Na začátku nebylo nic a potom byl framework.

Uvedu vlastní zkušenost. Ve svém stávajícím zaměstnání jsem čekal několik měsíců na memcached (z legal důvodů). Bylo rychlejší napsat si vlastní memcached-like service (dva dny práce) a až mi byl memcached dodán, bylo snadné je prohodit.

Nechme na tazateli, jestli si vybere all-in-one řešení na jednoduchou věc, nebo si vytvoří vlastní "from scratch" a přitom se třeba i něco naučí. Ani jedna cesta není špatná.


> Obzvlast pro vyukove ucely je skutecne vhodne vybrat dobra reseni, v
> tomto pripade tedy neco ze std knihovny nebo neco co funguje a plni
> sliby
> 
> Nejhorsi co se muze stat je, ze se nekdo nauci spatne postupy a
> principy, proto je vzdy dulezite, obcas i za cenu komplexity (django
> vs flask) nebo extra zavislosti (gunicorn nebo twisted na normalni
> server vs custom tcp socket), zvolit reseni ktere podporuje dobre
> navyky. V tomhle pripade je dobry navyk i nevynalezat kolo.

[toc] | [prev] | [standalone]

Back to top | Article view | cz.comp.lang.python

csiph-web