[python] Statické metody v Pythonu

[Petr Prikryl]

> > Ano. Ale toto je otázka návrhu. Typicky se definuje operátor
> > pro sčítání (operator+() nebo __add__()), který pracuje s
> > argumentem stejné třídy, jako je sám objekt. V budoucnu si můžu
> > vymyslet další konverze, ze kterých vypadne úhel. Z hlediska
> > údržby je lepší, když se speciality dělají zvenku. Je tedy
> > lepší venku převést string zeměpisné šířky na úhel a
> > dosadit.
> 
> A proč tedy můžu v Pytonu psát:
>      unicode_string + ansi_8_bit_string
> Proč v rámci tohoto pravdidla Python striktně netrvá na:
>      unicode_string + uniocde(ansi_8_bit_string)
> 
> Ono toto pravidlo, kdyby se mělo striktně dodržovat, 
> pak bude každý programovací jazyk včetně Pythonu ukecaný
> jako COBOL, nebo Ada.

Je to věc návrhu. Z logického hlediska unicode_string je
řetězec a ansi_8bit_string je taky řetězec. Bylo to jasné
už v okamžiku, kdy se ten operátor zaváděl. Taky bylo jasné,
že řetězce se budou používat intenzivně. Ale taky platí,
že žádný další typ se takto k řetězci přidat nedá! Nemůžu
tedy udělat
             unicode_string + 123

I když nadefinovat příslušný operátor by bylo možné 
a relativně snadné. Jenže za chvíli bych si mohl vymyslet,
že chci k řetězci přidávat kde co. Pro objekty to jde
vlastně podobně, jako kdyby se v C++ implicitně použil
dříve zmíněný konstruktor (tentokrát řetězce), který by
definoval konstruktor pro daný argument. Ale jde to jen
pro objekty třídy, které definují metodu __str__(). 
To je ale přístup z druhé strany. Jde to vlastně tehdy,
když objekt EXPLICITNĚ definuje konverzi na řetězec. 
Metoda __str__ je svým způsobem výjimečná -- cokoliv
často potřebujeme převádět na řetězec.

A to je podle mého názoru i odpověď na to, proč by se 
němělo dělat něco jako 

     uhel + "30N54"

Řetězce mají přece jen výsadní postavení. Při jejich 
vytváření se dokonce používá speciální syntaktická 
konstrukce. Ale stejně mohou nastávat problémy, protože
k ne-unicode řetězci musí někde existovat dodatečná 
informace, jaké kódování je použito.

>  > Readability counts.
>  > Special cases aren't special enough to break the rules.
>  > In the face of ambiguity, refuse the temptation to guess.
>  > If the implementation is hard to explain, it's a bad idea.
>  > If the implementation is easy to explain, it may be a good idea.
> 
> Pod to se podepisuji.

To nemůžeš. Pod tím už je podepsaný Tim Peters ;)
 
> [...] Já jsem taky původně váhal, jestli namísto 
> třídy Angle neudělat prostě pár normálních funkcí 
> a třídou se vůbec nezatěžovat. Na jednodušší věci 
> by to možná bylo lepší, prostě by zbytečně nevznikaly 
> instance, všechno by byl float. Ale nakonec jsem 
> se rozhodl pro komplexní řešení včetně operátorů, 
> property a dalších.

Je v tom skrytý určitý odpor k OOP (přílišný
konzervatismus -- neber to jako výtku). Pokud 
vyjádření "zbytečný vznik instance" nahradím
vyjádřením "zbytečný vznik proměnné", pak to vypadá
divně. Přitom vznik instance třídy nemusí být
v daném jazyce o moc náročnější, než vznik 
proměnné (ve smyslu jak to chápou kompilované
jazyky). Když použiji float, v Pythonu taky 
vzniká instance nějakého objektu.

pepr