Má Python budoucnost?

[javaman]

Mimochodem Python je tu opravdu tak popularni? Vsude v inzeratech totiz vidim jen Javu a C# na ty velke veci. Na male naopak jen PHP .

Samozřejmě není. Na malé projekty klidně. Často startupy, ale ty nemají peníze. Pokud chceš normální peníze, tak na Python zapomeň, ten je tak za půlku. Asi to není náhoda...

[Reklama]

[atarist]

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

No a nekdy to tak není a přístup k atributu přes getter či setter dává perfektní smysl. Co je na tom tak těžkého k pochopení? Navíc to perfektní zapouzdření je blbost, kdyby se vnitřní stav nějak neprojevil na chování objektu, nemusí tam ty atributy být vůbec že :-) Takže zapouzdření samozřejmě ano, ale pokud někdo cítí potřebu získat přístup například ke klasickému hodnotovému objektu a jeho atributům, nevidím v tom problém, i když třeba FP přístup má jiné prostředky (imho lepší, ale to je spíše na jinou debatu)

[gl]

__háky__

Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.

Zcela uprimne - prijde me to ohavne, to jsem od "krasneho" jazyka necekal. Proc radeji nezvolili jiny znak, pouze 1 znak, jako prefix, proc radeji 2x 2 podtrzitka?

Reflexe je i v jinych jazycich (jestli to chapu dobre) a vetsinou je povazovana za zverstvo, ktere se smi pouzivat pouze ve velmi specifickych pripadech typu knihovny kvuli hezci syntaxi. Podobne jako eval v JavaScriptu. Ma sice sve misto, ale v normalnim projektu typu web to misto rozhodne neni.

Nechápete to dobre. Já bych magické metody popsal jako rozhraní, které je společné všem objektům. S reflexí to nemá mnoho společného.

nutnost predavat metodam self a uvadet self pro pristup k poli objektu

Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.

Troufam si rict, ze v JavaScriptu jsem davno prekrocil zaklady, a rozhodne nemam v lasce nutnost vsude ve tride uvadet "this". CoffeeScript to vyresil celkem elegantne, misto "this" prisel s jednim znakem - @. Po pravde az v Pythonu vidim, ze se musi pouzivat this/self i jako parametr metody. Nevim, ja to vse vnimam tak, ze je to do Pythonu dolepene.

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

[noef]

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

Dik za vysvetleni.

Tak ale v tom pripade je Python jeste mene "OOP" nez Java, pokud v podstate nema zapouzdreni, nebo ne?

Jinak to oddeleni dat od funkci zni jako FP, uz jen chybi se zbavit tech setteru .

[javaman]

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat!

[Reklama]

[gl]

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat!

Jak píše Kit výše. Psaní self zlepšuje čitelnost. Oproti Javě toho pořád dokola jako retard moc nepíšu. Dekorátory v Javě opravdu nefungují. Dekorátor v pythonu je něco jiného než návrhový vzor dekorátor.

[noef]

__háky__

Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.

Zcela uprimne - prijde me to ohavne, to jsem od "krasneho" jazyka necekal. Proc radeji nezvolili jiny znak, pouze 1 znak, jako prefix, proc radeji 2x 2 podtrzitka?

Reflexe je i v jinych jazycich (jestli to chapu dobre) a vetsinou je povazovana za zverstvo, ktere se smi pouzivat pouze ve velmi specifickych pripadech typu knihovny kvuli hezci syntaxi. Podobne jako eval v JavaScriptu. Ma sice sve misto, ale v normalnim projektu typu web to misto rozhodne neni.

Nechápete to dobre. Já bych magické metody popsal jako rozhraní, které je společné všem objektům. S reflexí to nemá mnoho společného.

Jsem vychazel z wiki:

Metaobjects are examples of the computer science concept of reflection, where a system has access (usually at run time) to its internal structure.
...
A metaobject protocol (MOP) provides the vocabulary to access and manipulate the structure and behavior of objects.

To tedy dost pusobi jako reflexe ci prace s bytekodem, pokud to mam vztahnout k Java svetu. Ale je to asi jedno, me neslo o ty metaobjekty ani metaobjektovy protokol, ale o to inovativni jmeno: __*__, ktere bych nikdy neoznacil za hezke - coz uznavam je asi subjektivni a pravdepodobne o zvyku.

nutnost predavat metodam self a uvadet self pro pristup k poli objektu

Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.

Troufam si rict, ze v JavaScriptu jsem davno prekrocil zaklady, a rozhodne nemam v lasce nutnost vsude ve tride uvadet "this". CoffeeScript to vyresil celkem elegantne, misto "this" prisel s jednim znakem - @. Po pravde az v Pythonu vidim, ze se musi pouzivat this/self i jako parametr metody. Nevim, ja to vse vnimam tak, ze je to do Pythonu dolepene.

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

A opravdu tuto "vyhodu" vyuzivate tak casto, ze si to ospravedlnuje pridani jednoho parametru do kazde metody instance? To uz me prijde lepsi zpusob jak to ma Java nebo JavaScript - this je implicitni a pouze pokud opravdu chceme, tak muzeme podstrcit jine (v JS Function.apply/call, v Jave tusim reflexe), ale nemusime ho vsude uvadet.

PS: Jsem moc pomalej, javaman me predbeh .

[javaman]

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat!

Jak píše Kit výše. Psaní self zlepšuje čitelnost. Oproti Javě toho pořád dokola jako retard moc nepíšu. Dekorátory v Javě opravdu nefungují. Dekorátor v pythonu je něco jiného než návrhový vzor dekorátor.

Jak to může zvyšovat čitelnost? Oproti Javě tam pořád píšeš self jak retard. Anotace v Javě nejsou?

[Kit]

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

No a nekdy to tak není a přístup k atributu přes getter či setter dává perfektní smysl. Co je na tom tak těžkého k pochopení? Navíc to perfektní zapouzdření je blbost, kdyby se vnitřní stav nějak neprojevil na chování objektu, nemusí tam ty atributy být vůbec že :-) Takže zapouzdření samozřejmě ano, ale pokud někdo cítí potřebu získat přístup například ke klasickému hodnotovému objektu a jeho atributům, nevidím v tom problém, i když třeba FP přístup má jiné prostředky (imho lepší, ale to je spíše na jinou debatu)

Úkolem objektu není prezentace atributů, ale sebe sama. Je tedy v pořádku metoda toString(), která ten objekt prezentuje jako celek. Podobně by mohla fungovat i metoda toJson() nebo toMap(), které by prezentovaly stav objektu v jiných formátech. Dělat to posloupností volání getterů a teprve venku z toho slepovat nějakou datovou strukturu je blbost. To se dá pohodlně udělat uvnitř.

Podobně je tomu i s modifikací. Základem je kvalitní konstruktor, který vyrobí validní objekt se všemi nadefinovanými atributy. Modifikace se pak děje prostřednictvím zpráv, které obsahují informace vhodné k uložení - nebo také k ignorování. Modifikační metoda by neměla být pouhým setterem, protože ten obvykle mění jen jeden atribut. Je to způsob předání zprávy. Objekt si sám určí, jak s touto zprávou naloží a které atributy bude modifikovat. Opět je zcela zbytečné, aby vně objektu byla data parsována, validována a předávána objektu po jednom atributu. Prostě se data pošlou objektu jako celek a příslušná metoda uvnitř si je zpracuje. Ve své podstatě je to také setter, ale nenastavuje jen jeden atribut, jako je tomu zvykem u běžných setterů. Proto by ani nebylo příliš vhodné ho jako setter nazývat.

[BoneFlute]

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

Tak to určitě...

[gl]

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat!

Jak píše Kit výše. Psaní self zlepšuje čitelnost. Oproti Javě toho pořád dokola jako retard moc nepíšu. Dekorátory v Javě opravdu nefungují. Dekorátor v pythonu je něco jiného než návrhový vzor dekorátor.

Jak to může zvyšovat čitelnost? Oproti Javě tam pořád píšeš self jak retard. Anotace v Javě nejsou?

Anotace dělají něco jiného.

[javaman]

Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?

[Kit]

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

Dik za vysvetleni.

Tak ale v tom pripade je Python jeste mene "OOP" nez Java, pokud v podstate nema zapouzdreni, nebo ne?

Jinak to oddeleni dat od funkci zni jako FP, uz jen chybi se zbavit tech setteru .

Je to zapouzřeno. Data i metody pro práci s nimi jsou uvnitř jednoho objektu. Každý aplikovaný přístup zvenčí do atributu, ať již přímo či nepřímo prostřednictvím getteru/setteru je porušením tohoto zapouzdření. Java se proti tomuto porušení zapoudření umí bránit, Python ne. Je to součást jejich designu. Zapouzřeno však je obojí. Tedy za předpokladu, že to programátor zapouzdřit chce a umí.

V Javě ani Pythonu by se k atributům objektu z vnějšku přistupovat nemělo. A to ani prostřednictvím getterů/setterů. Mělo by se pracovat přímo s objektem, tedy volat jeho metody, které data uvnitř objektu zpracovávají jak pro vstup, tak i pro výstup.

[Kit]

Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.

Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat!

V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?

[Youda]

Ano, priznavam, ze puvodni OOP neznam (aktualni prakticky pouzivane OOP ano). Ale nejak se mi nepozdava, ze treba zapouzdreni by tam chybelo, coz snad ty modifikatory pristupu zajistuji.

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

Je pekne, ze sis vsiml existence design patternu ModelViewController (opet Gang of Four), lec tento OOP pattern opravdu na OOP pranic neboura ani nedeformuje.
MVC je uroven abstrakce nad OOP.
Pokud servisni class primo potrebuje nejake svoje atributy, napr URL na WebService nebo JDBC konexi, no tak je ma hezky u sebe.
Data modelu jsou v jinych objektech, obvykle nejaka collection/shluk Beanu. Beany uz ze sve definice nejsou nic jineho nez datova stuktura, tam opravdu jine metody nez gettery a settery nenajdes.

MVC design pattern oddeluje business logiku aplikace (controller) od statove/datove prezentace (model) a prezentace uzivateli (view)
Zkracene view zobrazuje userovi aktualni stav modelu, user klepe na buttonky, cimz controller meni model a ten se zase zobrazuje uzivateli.

Na MVC patternu ostatne funguje Django.