Názory k článku Hra Breakout napísaná v Tkinteri

za pěkný článek s popsaným kódem hry, která ve mě vyvolává silnou nostalgii.

Za clanek...
(Jen ty zavorky v ifu fuj a ani je nemas vsude, ale to je kazdeho vec...)

Ahoj,
hru jsem nezkoušel, ale ten kód se mi ani trochu nelíbí. Určitě bych ho nenazval "idiomatic python".

if (self.ball_x + self.ballvx > co[0]
                and self.ball_x + self.ballvx < co[2]
                and self.ball_y > co[1]
                and self.ball_y < co[3])

Proč ne raději takto?

if all(( self.ball_x + self.ballvx > co[0], self.ball_x + self.ballvx < co[2],
         self.ball_y > co[1], self.ball_y < co[3] ))"

Ještě lépe proč raději nevytvořit novou metodu?

if checkRanges(co, self.ball_x, self.ball_y, self.ball_vx, self.ball_vy):

Toto se vůbec nedá luštit. Co to proboha počítá?

d = hex(int(c[0]*256)<<16 | int(c[1]*256)<<8 | int(c[2]*256))

Celkově je ten kód takový neuhlazený, třída "Example" je typický zástupce God object

D. Knuth vyslovil citát: It was nice to learn Python; a nice afternoon. To je možná pravda, ale idiomatic python se za odpoledne nenaučíš, ten příchází až po letech...

Tak jde o to, ze podle meho clanek nema za cil ucit python, ale spis upozornit na zajimavou grafickou knihovnu, algoritmus kolizi se taky hodi pro inspiraci.
Kdo chce a stoji mu to za to, muze si to zkusit prepsat do 'idiomatic python' nebo treba do javascriptu :-)

Ja jsem rad ze si to muzeme se synem rozpitvat, testovat ruzne upravy a treba se neco noveho naucit.

Takze diky za clanek!

dobry priklad ma byt dobry po vsech strankach. od obsahu pres cisty kod po korektni cestinu.

To s tím d = hex(int(c[0]*256)<­<16 | int(c[1]*256)<<8 | int(c[2]*256)) mi zas tak nepochopitelný nepřipadá, ale python neumím, začínal jsem v asm na osmibitech, pak jsem přeskočil na C/C++, programováním se neživím, asi mám tímhletím pokřivený uvažování :-)

Řekl bych, že pokud s tím D. Knuth strávil celé odpoledne, tak to bylo včetně idiomatic stylu ;-)

Článek jsem jen prolétl, ale ... Závorky kolem jednoduché podmínky jsou nadbytečné, naopak v případě více podmínek jsou závorky, tak jak je píše autor, podle doporučení PEP (lze použít i nedoporučení hodný backslash). Funkce `all()` je dalším řešením -- zkoušel jsi rychlost all() vs "normální" zápis? Vychází mi to v průměru 2 x rychlejší bez volání funkce -- ale to tady není důležité.

Je to otázka zvyku, já používám zpětné lomítko místo závorek, je to jedno, účel stejnej. (Je to dáno asi tím, že sem v pythonu začínal, tedy nemám návyky z jinejch jazyků, s těma sem začal až pak...)
all() bych rozhodně v tomhle případě nepoužíval, už jen proto že rychlost. Je to logické, All je na procházení seznamů, tedy nejprve se seznam musí vytvořit a pak teprve prjít. Při klasickém and se vyhodnocuje z leva do prava, tedy pokud neplatí první podmínka, vrátí se False a dál se nic nevyhodnocuje...

On to zase takovy cukr neni; all() je normalni funkce, ktera vyhodnocuje, zda vsechny prvky nejakeho iterovatelneho objektu (zde tuple - ntice) jsou True (nebo ekvivalenty - viz pythonni logicke vyrazy).

Uprimne, tohle mi neprijde jako moc stastny zpusob zapisu. all() ma podle me smysl pro testovani generatoroveho vyrazu s dynamickym obsahem. Oproti ifu to sice usetri par znaku, ale nejakou uzasnou vyhodu v tom nevidim. Slozitejsi vyrazy s and i or se stejne musi psat s podminkou, takze co - abychom byli cool, tak pokud tam jsou same konjunkce, dame tam all(), pro disjunkce dame any() a kdyz to nejde jinak, holt pouzijeme if? Za me radeji konzistetne s ify.

Souhlas.

Nic závratného...
def all(iterable):
for element in iterable:
if not element:
return False
return True

https://docs.python.org/2/library/functions.html#all

Díky za článek !
Je vidět, že psaní GUI v Tcl/Tk technologiích je krásně jednoduché.

Na druhou stranu, nejsem si jistý, jestli podobné knihovny nejsou v současnosti používané za "OUT". Mám pocit, že aplikace z tohoto ekosystému většinou moc nezapadají ani do vzhledu, ani do návyků větších grafických prostředí.
Co si myslíte - má to cenu - učit se to ?