Názory k článku Nový chřestýš (1)

1) Python není chřestýš ale HROZNÝŠ, což je dost podstatný rozdíl protože chřestýš vás pohryže zatímco hroznýš přiškrtí.

2) Pokud vím tak Python se nejmenuje po hadech, ale po "Monty Pythonově Létajícím Cirkusu", ale to jen tak na okraj.

Nesmite hned verit prvnimu slovniku, co vam prijde do ruky :)

Python - Krajta (napr. Python Regius, Python Reticulatus)
Boa - Hroznys (napr Boa Constrictor)
Rattle Snake - Chrestys

udelejte si uz v tech hadech poradek.. vsichni :)

update:
Crotalus - Chrestys, tamto je jen anglicky :))

a s tim kousanim je to tak, ze krajta sice taky skrti, ale obcas si i kousne (a neni to prijemny :))

Dobrá, ale doufám že se shodneme že krajta se ke své oběti především lísá (a přátelsky ji obtáčí).

Hlavne chrestysi jsou na rozdil od krajt jedovati(jedni z nejjedovatejsich), takze to jejich kousnuti je vice nez neprijemne :-D

no, prave ze to od chrestysu az tak neprijemny neni... teda aspon ne moc dlouho ;)

Python muze byt klidne i hroznys. Hroznys i krajta patri do stejne celede hroznysovitych, a anglicky python znaci bud celou celed (tj. hroznyse i krajtu)0, nebo pouze krajtu (coz je v systematice podceled). Boa je hroznys, to je jednoznacne.

Dobrá, dobrá, je to krajta, ale čeleď hroznýšovitých.

Ahoj vsem,
v nazvoslovi hadu mam pravda trochu problemy. Priste se tedy budu drzet kobry :) Dekuji, ze jste mi v tom udelali poradek.

Jinak Python je sice podle Monty Pythona, ale stejne na to nikdo nehledi a kazdy mluvi o svem hadovi.

Kobry, nebo corby ? ;-)))

Ne kobra! Krajta! Kobra je zase uplne jiny had.

Python neovladam, nicmene se na nej chystam(o zkouskovym snad bude konecne cas;)). Zarazi me vsak jedna vec:
Proc vlastne existuji typy list i tuple? Neni to v podstate jenom kvuli usnadneni prace interpretru-rychlejsi prace se statickou promennou? Pokud ano, tak mi prijde nesystemove. Proc by se mel programator ve vysokourovnovem jazyce starat o rychlost programu? O to by se mel starat interpretr/prekladac/VM. (pryc jsou(snad) casy, kdy jsme psali 'xor ax,ax';))
Z podobneho soudku mi prijdou strucne generatory...
Snad se mylim, python skoro neznam, ale tohle me trosku zarazilo...
BTW:Kdyz jsem u toho prekladace, nevite nekdo, jak to vypada s ironpythonem?Dost me laka mod_mono ve spojeni s pythonem...<flame>PHP SUXX</flame> :D

Hlavní argumenty pro existenci tuple jsou jiné. Především klasický seznam není možno použít jako klíč ve slovníku, protože je možné měnit jeho obsah a nelze proto zaručit konstantní hash hodnotu.

Generátorový výraz jako takový samozřejmě nutný není, stejně jako "stručný seznam". Oproti klasickému generátoru je výhoda pouze v lepší čitelnosti, pokud se použije s rozumem. Generátor jako takový má samozřejmě výhod spoustu, ikdyž i on by jistě šel nahradit třeba instancí nějaké třídy, ale v mnohých případech opět na úkor čitelnosti programu.

Odpoved z trosku jineho uhlu:

1. Tuple a list maji v Pythonu jiny ucel. Tuple se obvykle pouziva namisto struktury nebo zaznamu (konstantni pocet polozek ruzneho typu), napriklad pri vraceni vice hodnot z funkce. Kdezto list se pouziva obvykle jako seznam nebo pole (promenlivy pocet polozek stejneho typu).

2. Strucne generatory jsou prirozene zobecneni strucnych seznamu na iteratory. Strucne seznamy byly zavedeny pro lepsi citelnost funkcionalnich konstrukci, ktere predtim vyuzivaly vestavenych funkci map a filter. A jsou velmi uzitecne, pokud zkusite v Pythonu neco napsat, protoze umoznuji zkratit nepodstatne (z hlediska cteni kodu) smycky do jedne srozumitelne radky.

Sorry, Honzo, ale tady jsi to s těmi novotvary IMHO trošku přehnal. Mnohem lepší, výstižnější a bližší originálu by byl třeba *generátorový výraz* (teď vidím, že je použit i v perexu). Já vím, že se Ti to rýmuje se "stručným seznamem", o kterém jsme v minulosti debatovali, ale zatímco u něj se ještě jakž takž dalo najít nějaké opodstatnění, tady už ho hledám marně. Je to podle mě jenom zdroj zmatku.

Jinak je článek fajn, novinky v Pythonu 2.4 si o rozebrání přímo říkaly.

Takze nas ceka nova diskuze nad Glosarem http://www.py.cz/Members/honza/preklad-1.2.html , uz se tesim. Pres zkouskove obdobi zpracuji navrh a pak se necham rozcupovat v diskusi python@py.cz :)

největší kverulant sekyru vykopat nehodlá. Ale jinak návrh samozřejmě vítám.

Moc nechválím, spíš kritizuju, tak si važte toho važte, že se mi tenhle článek líbil :-))))).

O.

Po dlouhé době dobrý článek na rootu, tehle človíček ví něco nejen o Pythonu, ale i o programování. Divím se, že má vůbec čas psát takové články.

Jen drobna poznamka, Python je dnes v prvni rade OOP jazyk, ktery umoznuje i proceduralni a funkcionalni pristup k programovani, objektum ale neni mozno se vyhnout.

Jen male upresneni. Python je predevsim proceduralni a funkcionalni jazyk s prapodivnou podporou OOP. Tohle je muj pohled :-)

To me docela prekvapuje, vzhledem k tomu, ze dnes je v Pythonu prakticky vsechno objekt. Na zaklade ceho u soucasneho Pythonu soudis ze je predevsim proceduralni a funkcionalni?

Nejde o to, zda Python objekty tvoří, ale zda jeho syntaxe objekty skutečně systematicky a konzistentně využívá.


Tyto dvě věci spolu bezprostředně nijak nesouvisí.
Když to přeženu, můžete implementovat třeba BASIC ve SmallTalku, ale stále místo metod objektů používat funkce (například místo hacku array.__len__() používat len(array), což je případ Pythonu).

V tom pripade je snad jediny skutecne objektovy jazyk (z tech pouzivanych) Smalltalk, ktery nema ani prikazy pro podminku a cyklus. Python podporuje ruzna paradigmata a nezastava filozofii "bondage & discipline". Diky tomu neni treba psat "Hello world" takovym zvirecim zpusobem jako treba v Jave, ale na druhou stranu Python dusledne pouzivani objektove metodologie umoznuje. Je mozne si snadno odvodit vlastni tridy od sekvencnich typu a tam si nadefinovat metodu length(), ktera bude volat len(self). Udelat patch, ktery takovou metodu prida primo do puvodnich objektu, by jiste nezabralo moc casu. Ale nevim, jestli by to bylo k necemu dobre, krome uklidneni "objektovych dusicek".

Syntaxe rozhodne neni to, co dela objektovy jazyk objektovym.

Ze zbezneho pohledu, ktery jsem venoval aspektove orientovanemu programovani se mi zda, ze dekoratory tomu docela odpovidaji, takze by se python dal take prohlasit za aspektovy programovaci jazyk.

Strucne: aspekt -- funkcionalita, ktera jde napric tridami a metodami (typicky priklad -- logovani -- kdyz chci logovat volani funkci (metod), chci aby to bylo pro vsechny stejne, nezavisle na tom, v jake tride tride metoda je.)

V pythonu si muzu definovat dekorator treba log_call
a funkce, ktere se maji logovat si jim odekoruju.
Kdyz nebudu chtit logovat do souboru, ale do databaze, jenom na jednom miste preprogramuju dekorator.

... z novinek v jazyce jsem uz nadsen mene. Kdyby radeji prevrtali nektere casti frameworku nebo pridali nove namisto zasahu a novinek v jazyce. Nevim, mozna jsem sam, ale tyhle "novinky" spis "spiny" cistotu, nadhernou jednoduchost a vzdusnost pythoniho kodu. Amen. :)

Pardon, ja to po sobe cetl, 2x, 2x blbe. :)

Oprava :

... ale tyhle "novinky" spise "spini" cistotu ...

No mě se ty novinky docela libí. Třebas to staticmethod() je podle mě docela vopruz, a často jsem na to zapomínal ...

me se taky zda, ze python smeruje k schizofrenii mezi imperativnim a funkcionalnim jazykem... zacina byt prilis mnoho cest jak napsat jednu vec a to ja nemam rad. ale vetsine to asi vyhovuje

Dojde-li na http://www.python.org/peps/pep-3000.html, tak se nám ten počet způsobů zase pěkně zredukuje...

no ti sice jo, ale me se v tom navrhu nelibej zase jiny veci. treba with (with se zda jako dobrej napad v jazyce, ktery ho nema, ale kdyz se clovek k dostane k jazyku, ktery ho ma, tak brzo zjisti, ze to bez nej bylo prehlednejsi), nahrazeni printu funkci, odstraneni retezcovejch vyjimek (k cemuz uz bohuzel doslo) a tak...

Proti with bych úplně nebyl (znám ho ale jen z pradávných dob z Pascalu), i když se mi vůbec nelíbí ta tečková notace -- IMHO se měla prostě přidat další (vnitřní) scope.

print jsem nikdy nechápal, proč není funkce, vždyť je to naprostý BASICismus (nebo perlismus -- stejně jako exec). A řetězcové výjimky jsem nikdy nepoužíval.

Python začíná být nějak nechutně přeplácaný. Líbil se mi víc jako jednoduchý jazyk, kde se některé věci musely sice obcházet, ale byl tak nějak konzistentní a člověk si ho mohl snadno a rychle osvojit. Jestli budou implementovat každou pitomost o kterou si komunita řekne (třeba volitelná podpora typů) tak dopadne jako Perl, o kterém jeho tvůrce údajně prohlásil něco jako: "je tak špatný, jak ho uživatelé chtěli mít." (neručím za správnost)

Mozna jeste uzitecnejsi nez na velkych seznamech jsou strucne generatory na iteratorech, co generuji svoje prvky za behu (typicky generatory).

Uvazte priklad:
lines = (line for line in file if line[0]!="#")

Soubor muze mit klidne 2 GB radku nezacinajicich # a kdyz se lines posle treba nejake funkci ke zpracovani, tak to bude fungovat. Kdyby tam byly hranate zavorky, tak se to ony 2 GB bude snazit naladovat do pameti a pravdepodobne skonci neuspechem.

Stejneho efektu lze ve starsich kobrach (ci v cem? :-)) dosahnout jen vytvorenim celeho generatoru:

def good_lines(f):
__for line in f:
____if line[0]!="#": yield line

...

lines = good_lines(file)

Myslim, ze strucne generatory jsou o neco prehlednejsi.

(ty _ jsou tam misto mezer kvuli odsazeni)

Jenom menší doplnění - v novějších verzích Pythonu (od verze 2.2?) stačí použít for line in f:, efekt je stejný. Není třeba psát generátor, tato konstrukce iteruje soubor po řádkách a do paměti se žádný seznam neukládá.