[python] Statické metody v Pythonu

[superman]

> 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.

Ono je to také diskutabilní, co má být výsledkem operace

unicode_string + 123

Má se to sečíst jako řetězce, nebo jako čísla?

Ale přiznávám, je mi Python sympatický tím, že to za mě neřeší. Takže 
Vám dávám za pravdu.

> 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.

Přesvědčil jste mě. Asi je pravdou, že konverze čehokoli na řetězec je 
velmi přirozená operace. Takže je to takový výjimka z pravidla. 
Automatické konverze řetězce na něco asi může vést k mnoha nečekaným 
chováním. Takže nejspíše škrtnu všechny automatické konverze stringu na 
úhel kromě konstruktoru a metody assign.

Teď ještě budu řešit, jestli povolit automatické konverze floatu na 
úhel. float by měl význam velikosti v radiánech. Takže zatím s mojí 
třídou jde:

uhel = uhel - float v radianech

akorát uz v tom začínám mít nepořádek, protože třeba:

===

uhel / float mi dává jako výsledek uhel
(tedy float tady má význam normálního čísla, kterým se úhel dělí)

uhel / uhel mi dává jako výsledek float
(dva úhly jako výsledek dávají jen číslo, tedy poměr dvou úhlů)

float / uhel mi vyhazuje výjimku jako neplatnou operaci

===

ale třeba jiná operace:

===

uhel + uhel = uhel
(součet úhlů)

uhel + float = uhel
(float se převede na radiany a zase je to součet úhlů)

===

Takže se možná dohrabu i k tomu, že float bude nutné explicitně 
přetypovat na úhel a bude tam tedy vznikat zbytečná instance a bude 
alespoň jasno. Ještě zatím váhám. Takže nakonec asi budete mít pravdu a 
udělám to tak jak jste mi doporučoval hned na začátku.

>>Pod to se podepisuji.
> To nemůžeš. Pod tím už je podepsaný Tim Peters ;)

A sakra :-) Zase ty patenty a autorská práva :-) Asi se budu muset stát 
rebelem a prosazovat pravý opak, jinak narazím :-)

> 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.

Pravdu určitě máte. Určitý odpor, já bych to nazval možná diplomaticky 
skepticismus vůči OOP mám a to přesto, že mě ani nenapadlo bez OOP 
cokoli za poslední léta programovat. Ptám se jak mi OOP může pomoci 
realizovat můj cíl.

Faktem asi je, že když Python tvoří float, asi je to pro něj podstatně 
náročnější, než float v C++, Javě, Pascalu, nebo jiném staticky 
typovaném jazyce. Protože si představuji (a možná to není pravda), že 
stejně Python vnitřně vytvoří nějaký objekt, poznamená si do něj typ 
(tedy float), poznamená si do něj počet odkazů (něco jako garbage 
collector), možná je tam i nějaká tabulka metod a nakonec ta vlastní 
hodnota floatu je to naprosté minimum. Naproti tomu vytvoření instance 
bude v Pythonu plus mínus to samé. Jediné co si myslím je, že prostě 
stejně instance objektu Angle v sobě nese navíc veškeré režie floatu a 
veškerých datových členů.

Ono nejspíš příliš optimalizovat je cesta do pekel. Největší náklady a 
ztráty vznikly zatím šetřením paměti. Problém Y2K stál obrovský balík 
peněz. A co problémů má Unicode, protože chtěli šetřit a připustili, že 
Unicode bude mít 16 bitové znaky namísto 32 bitových. Dnes už jsme 
stejně v Unicode překročili prostor 16 bitů, ale bordel nám zůstal.