Zdravím, Přidám svůj pohled na řešení problému s IP objektem a na pohled na výjimky (s ohledem na vaše vzdělání a působení).
S tím návrhem třídy IP bych se přimlouval k promyšlení pohledu na to, co objekt třídy IP reprezentuje. Zohlednil bych taky to, jak by to vypadalo v jiných jazycích, třeba v C++. Prakticky žádný jazyk neumožní korektní "nevznik" objektu -- pokud nedojde k nějaké nízkoúrovňové havárii. Objekt v kompilovaných jazycích buď vytvořím staticky, na zásobníku (jakoby staticky, ale v prostoru zásobníku) nebo dynamicky (new nebo něco takového). Jakmile vznikne, zpřístupňuji jej přímo přes jméno proměnné (statický objekt nebo na zásobníku -- tohle v Pythonu není), přes referenci (to je případ Pythonu) nebo přes ukazatel. Pouze v případě použití ukazatele mám možnost vrátit alternativně hodnotu NULL. Pak to musí být případ, který popisoval Petr Messner -- zavolat funkci a ta vrátí buď NULL nebo hodnotu ukazatele na vytvořený objekt. Tohle by v Pythonu bylo stejné. Při návrhu se musí rozhodnout, co vlastně objekt třídy IP má vyjadřovat. Má vyjadřovat zachycení přání vnějšího prostředí (uživatele, volajícího kódu) získat objekt s právě takovou IP adresou? Má existence objektu vyjadřovat platnost IP adresy? Co to vůbec je "platná IP adresa"? Je to syntakticky správně napsaná adresa, nebo je to adresa, která se dá skutečně použít? Nebo dokonce adresa, která mi umožní udělat operaci, kterou bych chtěl provést (tj. s ověřením, že se přes ni někam dostanu)? A co když se syntaxe IP adres v budoucnu změní? Jak to udělat, abych toho musel předělávat co nejméně? V tomto smyslu se přimlouvám za to, aby objetk třídy IP vznikl vždy, ale aby se bránil použití v případě, kdy má nepoužitelný obsah -- v okamžiku použití, nikoliv v okamžiku vzniku (viz například momentální nedostupnost přes IP). Na vyšší úrovni si pak můžu rozhodnout, zda objekt s nepoužitelnou IP adresou (po otestovnání jeho vlastností) ponechám nebo zruším. V tomto smyslu se přimlouvám znovu za návrh Petra Messnera -- využít __nozero__. Protože přesně pro tento účel byla metoda navržena. Ona se vlastně jmenuje blbě. Její jméno by mělo být odvozeno spíš z myšlenky "hodnota v boolovském kontextu". Ale vznikla v době, kdy Python místo True a False používal ještě 0 a != 0 (jako C). Pak nepotřebuji pomocnou funkci, ale objekt můžu použít k testování přesně stejným způsobem, jako bylo původně zamýšleno: ipaddr = IP("192.168.34536.45") .... if not ipaddr: print "zadavas blby vstup" Chování v boolovském kontextu implementované metodou __nozero__ navíc umožňuje dynamicky měnit "platnost" objektu podle potřeby. Teď k výjimkám. Souhlasím s názorem, že výjimky by se měly vyskytovat výjimečně. Ale spíše jde o to, že se výjimečným způsobem ošetřují. Co se týká výjimky StopIteration, tu považuji spíš za výjimečnou ;) Jde o to, že samotný cyklus for je v Pythonu proti "klasickým kompilovaným" jazykům trochu výjimečný. Není to počítaný cyklus. Je to zobecněný cyklus přes sekvenci. Existence StopIteration přestavuje jednu z mála možností, ja mohou všechny možné iterace dát najevo svůj konec (různé kontejnery, generátory...) A co se týká programování s výjimkami a bez výjimek, je to otázka změněného přístupu k tvorbě programu (podle mého k lepšímu). Když to srovnáváte s goto... Dříve "neřízené" používání goto způsobovalo těžko řešitelné problémy. Postupně to vedlo k "objevu" strukturovaného programování (Wirth jako představitel). Pořád ale bylo založeno na jednoduchém toku řízení. Proto bylo možné "následně" testovat, jak to dopadlo před chvílí. Ve školních příkladech se často "testování jak to dopadlo" pro jednoduchost vynechávalo... protože to zkrátka vede k zaplevelení kódu smetím, které není užitečné z hlediska abstraktního uvažování o problému. Jenže v praxi právě k tomuto jevu dochází a programy se stávají hůře čitelné (se všemi důsledky, jako třeba vznik dalších chyb díky bobtnání kódu). To testování se taky muselo dělat otrocky. Muselo se myslet na všechny možné situace, které mohly selhat. Při rozsáhlejším programu je to na mašlu. Objektové programování představuje další změnu pohledu ve smyslu "spolupráce kooperujících objektů". A i když se o tom programátoři v praxi zatím tak moc neuvažují, znamená to "potenciálně paralelní činnost" těch objektů. Potom už je velmi těžké uvažovat v kategoriích co bylo dříve a co později. Umělá serializace akcí vede k navození situace, kdy by se uplatnil Amdahlův zákon (úzké hrdlo paralelismu). Výjimka je v takovém případě výhodným komunikačním prostředkem, který bude fungovat i v paralelním prostředí. A opět, výjimečný není samotný objekt výjimky, ale způsob, jakým je jeho existence zpracována. V jazycích typu C++ získaly kdysi výjimky přívlastek těžkopádného nástroje. Ale bylo to proto, že existovalo méně zkušeností s tím, jak jsou užitečné a obtížně nahraditelné. A taky to souviselo s vývojem překladačů a s generováním kompilovaného kódu. A taky, v C/C++ se vše měřilo na mikrosekundy a vše je velmi rychlé. Nutná složitost se proto někdy neoprávněně zaměňovala za pomalou těžkopádnost. Ten změněný přístup při návrhu aplikace by se dal shrnout ve stylu: Naprogramuji to tak, jak by to mělo fungovat v ideálním případě a pak uvidíme. Selhání se mohou ošetřit "bokem". A ještě jedna výhoda výjimek. Když zapomenu něco otestovat v ifech (klasicky), může to krachnout velmi nepříjemně. Když někde neobsloužím výjimku, můžu ji krásně obsloužit v hlavní funkci (main). Mějte se krásně, pepr >--------------------------------------------------------- >Od: David Rohleder >Přijato: 24.3.2010 9:55:53 >Předmět: Re: [python] nevznik objektu > >Vladimir Macek píše v Út 23. 03. 2010 v 23:51 +0100: > >> On 19.3.2010 00:04, Jirka Vejrazka wrote: > >> > Davide, smir se s tim. Vyjimky jsou v Pythonu zavedeny, chapany a > >> > podporovany zpusob reagovani na chybove stavy, zejmena na > >> > neocekavana data. > >> > >> A i to je zbytecne uzky pohled na to, na co se daji vyjimky pouzivat. Za > >> prve, nekdy vubec nenesou chybovou informaci, ani nejsou spojeny > >> necekanymi daty. Prikladem je built-in > >> http://docs.python.org/library/exceptions.html#exceptions.StopIteration > >> Tedy vyjimka, kterou iterator indikuje, ze je vyprodano. > >> > >> Za druhe, vyjimky jsou normalni objekty, ktere mohou nest libovolna > >> data. Jakoby promenne, ale zpusobi zmenu provadeni programu zcela jinym, > >> ale predem danym a casto uzitecnym smerem (z vnoreni ven). > > > >Přesně na to jsem narážel, když jsem říkal, že někdo používá výjimky > >jako lepší goto (kterým navíc dokážeš vyskočit z funkce). > > > >> Nejcasteji > >> skutecne nesou podrobnou informaci o chybe vykonavani, ale nikdo nikoho > >> neomezuje v rozsireni tohoto modelu podle aktualnich potreb. > >> > >> > >> > Zkus to chvili nechat odlezet, treba se ti to zacne libit :) > >> > >> Za tohle se taky velmi primlouvam. > >> > >> Davide, podle toho, co pisete, jste na zacatku: Syntaxi a knihovnu treba > >> zvladate, ale jeste vas ceka krok prijmouti zpusobu mysleni, ktery > >> zkusenemu pythonistovi pomaha dosahnout vynikajici vykonnosti a elegance > >> kodu. To neni vycitka, naopak, jsem rad, ze se ucite a my ostatni vam > >> radi pomuzeme. > >> > >> Jen to, ze predcasne soudite a snazite se roubovat novy pristup na drive > >> naucene (coz clovek ma clovek tendenci povazovat za to lepsi), to je > >> mirne iritujici. > > > >Já to nějak nesoudím, akorát si snažím objasnit některé věci. Imho jsou > >napřiklad některé z těch syntaktických cukrů špatně - např. odstranění > >závorek z generátorů (i*i for i in range(4)). Ne, že by se na to nedalo > >zvyknout, akorát to tady trochu přehnali. > > > >Ještě pořád mně vy pythonu přijdou některé věci poměrně nešikovně > >vyřešené, ale to se časem vsákne. > > > > > > > >_______________________________________________ > >Python mailing list > >Python@py.cz > >http://www.py.cz/mailman/listinfo/python > > > >
_______________________________________________ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python