Názory k článku
Připravte se na změnu v Python 3.0
-
Ondra "Satai" NekolaZlatý podporovatelNeprilis prekvapive maji hodne kodu v Jave a dokonce opensourcovaneho. O GWT nebo Guice uz jste mozna slysel? -
Rejpal (neregistrovaný)Ano, to je zcela běžné, že se firma rozroste a klidně pak napíše kus dalšího softwaru v něčem jiném, než na čem stojí její "core business". Ale měl bych tu "anecdotal evidence" z oblasti, o které toho vím víc. Vezměte si třeba ITA Software. Kolem roku 2001 nebo tak něco napsali brutálně rychlý vyhledávač levných leteckých spojů v Common Lispu. A do světa pak pyšně vytrubovali, že každým řádkem Lispu ušetřili deset až dvacet řádků C++. A pak někdo (přesněji notorický flamer a provokatér Jon Harrop, který kope za Ocaml a F#, bohužel i v diskusních skupinách jiných jazyků, a to v ještě horším stylu než Svědkové Jehovovovi) poznamenal, že nemá důvod věřit, že by po sedmi letech malá firmička používala tentýž obskurní jazyk, proti kterému flamuje a do kterého se naváží už roky (a všichni se ho už naučili ignorovat). A vida, nakonec to nemohl vydržet a ozval se ozval Dan Weinreib (kdo ho zná, ví, že je to velký závorkový zvíře :-)) a potvrdil nejen to, že původní jádro jejich SW pracuje dodnes, ale že dokonce napsali hromadu dalšího lispového kódu. A jak? Prezentační vrstvu mají v Javě, engine mají v Lispu, storage backend je Oracle, a kus kódu okolo tvoří Python a Perl. Proč neudělali všechno v jednom? Inu, asi proto, že nemají dost lidí čistě na Lisp, protože pro Javu existují hotová řešení na tvorbu webových frontendů, která by jinde museli psát od nuly, protože Oracle má slušný track record, i když je to děsná bestie, a protože podpůrné věci jako SW pro údržbu nebo pomocné skripty je často jednodušší "zbastlit" v nějakém skriptovacím jazyku, pokud je jisté, že při selhání nenapáchají velkou škodu a že toto riziko je tak malé, že ho vyváží krátká doba vývoje a rychlý turn-around. Přijde mi celkem normální, že řídí-li se firma mottem "use the right tool for the right job" a pokud nepřepisuje SW ze dne na den podle akuální módy, skončí nakonec s poměrně heterogenní infrastrukturou. Jak říkám, tohle je "anecdotal evidence", ale je důvod domnívat se, že Google je na tom dneska jinak? Lidé na webu se rádi hádají, jestli je lepší C++ nebo Java nebo Python, a velká firma to pak stejně s velkou pravděpodobností používá všechno najednou podle potřeby a projektů.
-
xyzzy (neregistrovaný)Ale ne, nedoslo k odstraneni featur funkcionalniho programovani. Akorat je prehlednejsi misto map a filter pouzivat generatorove vyrazy, proto je tyto zabudovane funkce odstranili jako nadbytecne (a malo pouzivanou funkci reduce presunuli do standardni knihovny).
K tomu Google - oni maji na MapReduce vlastni jazyk, zvany Sawzall, ktery je i rychlejsi nez Python. -
Vy sam bez nich prezijete (i kdyz i autorovi to pomaha, kdyz si to dobre navrhne a nalajnuje), ale pri publikaci knihoven pro dalsi vyvojare je to dobra vec. Stejne jako interfaces a abstraktni tridy.
Podivejte se treba jak princip interfaces pomaha u J2EE a dalsich specifikaci -- servlet kontejnery implementuji J2EE a pritom zachovavaji rozhrani, protoze z principu fungovani jazyka proste musi :)
Pak mate mnohem vetsi jistotu, ze vam jedna aplikace pojede "vsude" (vsichni vime, ze na 100 % to tak nikdy neni). -
Python interfaces nepotřebuje, protože má násobnou dědičnost a interface není nic jiného, než nedokonalá náhražka násobné dědičnosti. Abstraktní třída určitě opodstatnění má, ale dá se bez ní také přežít - abstraktní metoda se v Pythonu emuluje pomocí výjimky NotImplementedError a pokud máme následující kód
class A(object):
....def a(self):
........raise NotImplementedError
class B(A):
....pass
Nástroj pylint pak mimo jiné hlásí:
W: 5:B: Method 'a' is abstract in class 'A' but is not overridden
Je jasné, že v Javě je ta kontrola striktnější a použití nástroje typu pylint vyžaduje programátorskou disciplínu. Nicméně analýza kódu při sestavování, jak vidět, možná je a dosáhnout kontroly dodržování rozhraní je možné také. Ještě lepší by ta situace měla být v novém Pythonu po zavedení anotací - ty umožní důkladnější kontrolu než jaká je možná doposud. -
Co se týče těch protected atributů, v Pythonu se často používá následující konvence:
name - public
_name - "protected" (== nech mě na pokoji, pokud je to jenom trochu možné)
__name - private
Jinými slovy, pokud člověk vidí identifikátor _name, zpozorní a ví, že na něj nemá šahat, pokud neví přesně, co dělá. Což je dostatečná pomůcka pro autora a vzhledem k filosofii Pythonu (we are all adults) i pro uživatele knihovny. Ten problém je spíš filosofický než technický. Statická analýza kódu při sestavování může pokusy o přístup k "protected" atributu velice snadno odhalit.
