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.
No musím se přiznat, že tomuto příspěvku vůbec nerozumím. Původní kritik mluvil o používání konstrukce len(obj) oproti třeba obj.length(). Syntaxe v tomto případě vůbec nic neřeší. Kdyby se v nějakém jazyce vyvolávaly metody objektu třeba pomocí callmethod(obj, methodname, (parameterlist)), nebylo by to o nic méně objektové, než obj.methodname(). Za implementaci chování je v obou případech zodpovědný objekt, resp. třída, která ho popisuje. Funkce len() v Pythonu jenom nepřímo volá metodu __len__, kterou si koneckonců můžeš vyvolat explicitně a to i u standardních sekvenčních typů - Python k používání len() nikoho nenutí. Ale co víc - na funkci len() lze nahlížet jako na statickou metodu modulu __builtins__, což je koneckonců také objekt, takže se nám "objektový kruh" krásně uzavírá.
Kdyby se ... vyvolávaly metody objektu třeba pomocí callmethod(obj, methodname, (parameterlist)), nebylo by to o nic méně objektové, než obj.methodname()....
Nedovedu si dost dobře v takovém případě představit třeba Intellisense a značná výhod OOP v tom případě přijde vniveč...
Zato já si dovedu intellisense představit docela dobře i v případě této poměrně absurdní syntaxe. Napsat rozumné IDE, které snadný zápis volání takových metod umožňuje, by neměl být žádný velký problém. A jaké výhody OOP že to přijdou vniveč? Paradigma se nezměnilo vůbec, jmenný prostor se tím nijak nezanáší, výrazové prostředky to neomezuje. Akorát se možná trošku sníží čitelnost a v klasických editorech musí napsat člověk o pár znaků víc. Žádné další nevýhody mě nenapadají.
A ještě něco. Spusť si interaktivní interpret Pythonu, napiš i = 1. Pak si nech vypsat dir(i). Uvidíš tam metody jako __add__, __sub__ apod. Zavolej si metodu 1.__add__(1), vypíše se 2. Takže, když to shrnu, klasický infixový operátor + je jenom zkratka pro operator.add(), který volá metodu obj.__add__(). To si myslím, že je dost dobré řešení a mnohé objektové či "objektové" jazyky jsou oproti Pythonu poněkud pozadu a Python se z hlediska objektovosti nemá zač stydět.
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.