Přesun od PHP k Pythonu?

[Petr]

Neni to jedno podtrzitko, ale dve a neni to dohoda programatoru, ale vlastnost jazyka. Takto pojmenovana metoda neni svym jmenem pristupna z venku, coz je nezbytne nutne k tomu, aby je bylo mozno prepisovat v odvozenych tridach.

to jako vážně? name mangling není analog private.

Ale je.

[Reklama]

[Petr]

Osobně bych od PHP neutíkal. Python je zajímavý, ale hodně odlišný.

Pro mě osobně díky znalostem PHP nebyl problém něco dělat v Javascriptu a napsat si například plugin pro Visual Studio Code editor. A to stejné platí pro C# nebo Javu - ten přechod není vůbec složitý a ačkoliv jsem dělal hlavně v PHP a posléze Javascriptu, nebyl pro mě problém upravit si nějakou aplikaci napsanou v C# pro mé potřeby. V Pythonu jsem napsal pár jednoduchých skriptů (ale jen proto, abych se s ním seznámil), prostě mi příjde, že s Pythonem se dá udělat vše, ale vždy je to druhá volba. Příklad: weby - ano, s Pythonem se dají psát weby, ale první volba je PHP (backend) nebo Javascript (frontend). Pro aplikace na PC C#, Javu nebo už raději C,C++ než Python, atd. atd. Ano, pokud budeš studovat matematiku na univerzitě, jistě bude Python skvělý nástroj, ale v praxi vždy najdu lepší řešení u jiného jazyku ...

Navíc, PHP 7 (7.2, 7.3) jde podle mě dobrým směrem.

Používám php, python i js. Otázka zda na web použít php nebo python je otázka nasazení. Na veřejný hosting je vhodnější php, na lokální weby python. Na desktopové aplikace s webovým rozhraním jednoznačně python. Na menší, jednodušší aplikace (do 50 000 řádků)  je první volba Python a jedině výkonostní důvody mě přimějí poohlédnout se po kompilovaném jazyku. A díky cythonu už vlastně ani to není zpravidla potřeba. Takže jedině paměťové důvody (jednočipy typu  Arduino) jsou důvodem, proč se obtěžovat z pohledu produktivity neefektivním C. Python je  výrazně flexibilní, pohodlný a produktivní, zvládne většinu úloh, takže jen málokdy je důvod k němu hledat alternativu.

[kate]

Pár takových jazyků už tady je, ale bohužel se moc neprosazují. Proč asi?

Rustu to zatím jakž takž jde

[mtd]

Řekl bych, že to bylo myšleno takto:
...
AttributeError: Cau instance has no attribute '__x'

no, ano, takhle se to chová.   vtip je v tom uvědomit si, že python nemá vůbec žádné řízení přístupu. takže si mylně interpretujete nepřítomnost symbolu jako nějakou jinou funkcionalitu.

name mangling je zřídka používaná funkcionalita, kterou potřebujete, když si třeba budete psát framework, co nutí uživatele podědit nějaké vaše třídy a současně uživatelům vašeho frameworku chcete zabránit některé metody overridovat nebo chcete zabránit kolizím v názvech. to znamená něco, jako javovské final.

[Kit]

Já bych všechny ty public a protected atributy zakázel, včetně getterů a setterů. Jenom to porušuje zapouzdření.

[Reklama]

[Jano7]

Já bych všechny ty public a protected atributy zakázel, včetně getterů a setterů. Jenom to porušuje zapouzdření.

Tak sa natíska potom otázka, treba nám vôbec to OOP? Musíme trebár pri webových projektoch použiť OOP paradigmu? Nemôže byť kontroller, service objet, obyčajná funkcia? JavaScript to rieši geniálne: dáta sú uložené v JSON databáze, z tadiaľ sa pošlú do aplikácie v JSON formáte, spracujú sa v JSON objektoch/kolekciách pošlú sa ako JSON klientovi a spracujú sa na klientovi v JSON. Netreba serializáciu/deserializáciu. Odpadá celý ten maglajz okolo zapúzdrenia, dedičnosti, final modifikátoroch, gettroch settroch, generátoroch, kadejakých lombock zbytočností. Nehovoriac o statickýc metódach či perzistencii dedičnosti v relačných databázach...

[Kit]

Tak sa natíska potom otázka, treba nám vôbec to OOP? Musíme trebár pri webových projektoch použiť OOP paradigmu? Nemôže byť kontroller, service objet, obyčajná funkcia? JavaScript to rieši geniálne: dáta sú uložené v JSON databáze, z tadiaľ sa pošlú do aplikácie v JSON formáte, spracujú sa v JSON objektoch/kolekciách pošlú sa ako JSON klientovi a spracujú sa na klientovi v JSON. Netreba serializáciu/deserializáciu. Odpadá celý ten maglajz okolo zapúzdrenia, dedičnosti, final modifikátoroch, gettroch settroch, generátoroch, kadejakých lombock zbytočností. Nehovoriac o statickýc metódach či perzistencii dedičnosti v relačných databázach...

OOP je výhodné používat kvůli přehledné architektuře kódu a vhodnému rozdělení kompetencí. Router bývá často implementován jako statická metoda, tedy de facto funkce. Kontrolery a pohledy je dobré mít právě jako polymorfní objekty. Vytvoříš si jen jednu instanci podle požadavku a vyleješ z ní data na výstup. Všechny pohledy dědí z jednoho View, všechny kontroléry mají jako rodiče jeden Controller. Je to elegantní a rychlé.

JSON vytvoříš v PHP pouhou serializací objektu, v tom problém nevidím. Maglajz kolem zapouzdření se nekoná, neboť k tomu potřebuješ pouze jednu veřejnou metodu jsonSerialize(). Pouze zavoláš json_encode($object) a dostaneš požadovaný JSON, který rovnou odešleš klientovi. Funguje to rekurzívně, jsou tedy serializovány i komponenty objektu.

[UPC manager]

Tak sa natíska potom otázka, treba nám vôbec to OOP? Musíme trebár pri webových projektoch použiť OOP paradigmu? Nemôže byť kontroller, service objet, obyčajná funkcia? JavaScript to rieši geniálne: dáta sú uložené v JSON databáze, z tadiaľ sa pošlú do aplikácie v JSON formáte, spracujú sa v JSON objektoch/kolekciách pošlú sa ako JSON klientovi a spracujú sa na klientovi v JSON. Netreba serializáciu/deserializáciu...

Aha, a co je tedy JSON.stringify() a JSON.parse() když ne serializace a deserializace mezi JS objektem a JSON?

[aaa]

Zkus si v Pythonu napsat neco co zaroven resis v PHP, zkus si dohledat jsk to udelat idiomaticky (tedy tak aby to nebylo PHP v syntaxi Pythonu) a uvidis, jestli se ti vysledek bude libit. Na trolly co resej zapouzdreni a pritom v zivote v Pythonu nenapsali nic poradnyho se vykasli, je  to pouzitelnej jazyk kterej se snadno uci, ale jako vsude: abys v tom psal hezkej kod nebude stacit si precist jeden tutorial. Jestli chces zustat u webu, tak PHP neopoustej, sila Pythonu je v machine learningu jak tu psal kolega vyse. Django je jen na weby, kdybys delal API pro server to server komunikaci tak mrkni na Flask. Casem se ti muze hodit Tornado nebo asyncio, ale to az budes vedet proc ho potrebujes a proc ti pro dany typ API Flask nestaci. Pokud ses zatim spolehal spis na ORM, nauc se dobre SQL, bude se ti to hodit. Drzim palce a zastav se na meetupu, nekdo ti rad poradi - mrkni se na python.cz a proklikej se ke srazu kterej mas blizko.

[Jano7]

Aha, a co je tedy JSON.stringify() a JSON.parse() když ne serializace a deserializace mezi JS objektem a JSON?

To by som skôr nazval pretypovanie alebo morfing.

[DragonMaster]

Určitě do toho jdi, ale budeš muset fakt makat, protože v Python už je level, kdy se skutečně programuje a člověk, co Python ovládá, tak má právo si říkat programátor. Nicméně, výsledek za to stojí. Přeji hodně štěstí...

[Kit]

Aha, a co je tedy JSON.stringify() a JSON.parse() když ne serializace a deserializace mezi JS objektem a JSON?

To by som skôr nazval pretypovanie alebo morfing.

Je to serializace a parsování. Objekty v Javascriptu nejsou uloženy jako JSON, ale ve formě stromu. Obousměrná konverze je tedy nutná.

[Petr]

Řekl bych, že to bylo myšleno takto:
...
AttributeError: Cau instance has no attribute '__x'

no, ano, takhle se to chová.   vtip je v tom uvědomit si, že python nemá vůbec žádné řízení přístupu. takže si mylně interpretujete nepřítomnost symbolu jako nějakou jinou funkcionalitu.

name mangling je zřídka používaná funkcionalita, kterou potřebujete, když si třeba budete psát framework, co nutí uživatele podědit nějaké vaše třídy a současně uživatelům vašeho frameworku chcete zabránit některé metody overridovat nebo chcete zabránit kolizím v názvech. to znamená něco, jako javovské final.

Vtip je v tom s uvedomit, ze tohle je pythoni pragmaticky zpusob jak efektivne docilit private atributu a metod. Mylne si to interpretujes akorat ty sam a jeste tu vykladas nesmysly o jednom podtrzitku a domluve mezi programatory. Skryvani metod a atributu pomoci dvou podtrzitek je standardni a bezne uzivana praxe, kterou akorat ty neznas a vrsis tu jeden nesmysl na druhy.

[Jano7]

Aha, a co je tedy JSON.stringify() a JSON.parse() když ne serializace a deserializace mezi JS objektem a JSON?

To by som skôr nazval pretypovanie alebo morfing.

Je to serializace a parsování. Objekty v Javascriptu nejsou uloženy jako JSON, ale ve formě stromu. Obousměrná konverze je tedy nutná.

Dobre, tak nech je to serializácia. V JavaScripte je však určite oveľa menšia réžia. Nevníma sa to ako ten tragický impendance mismatch.

Kód: [Vybrat]

let user = {
    "firstName": "Peter",
    "lastName": "Novak",
    "email": "pnovak@example.com"
 };

 let json = JSON.stringify(user)

 console.dir(json);

Vypíše:

Kód: [Vybrat]

$ node test.js
'{"firstName":"Peter","lastName":"Novak","email":"pnovak@example.com"}'


Pouze zavoláš json_encode($object) a dostaneš požadovaný JSON, který rovnou odešleš klientovi. Funguje to rekurzívně, jsou tedy serializovány i komponenty objektu.

V Java Springu stačí pridať Jackson dependency do buildu a máme automatickú konverziu do JSON, stačí len vrátiť kolekciu z kontrollera. Je to zautomatizované, ale tá réžia tam je. Niekto musel ten auto-kód naklepať, aby tá konverzia prebehla. Nedávno som študoval JSON-P v Jave, je to výborne navrhnuté, oproti starému JAXP. Otázka je, či to vlastne skutočne potrebujeme?

Koľko zbytočne komplikovaných vecí by sme zahodili! Kúpil som si knihu Java Language Features, tam sú na cca 30 stranách rozoberané inner classes. To je taká maličká čiastočka OOP...

[m.]

Neni to jedno podtrzitko, ale dve a neni to dohoda programatoru, ale vlastnost jazyka. Takto pojmenovana metoda neni svym jmenem pristupna z venku, coz je nezbytne nutne k tomu, aby je bylo mozno prepisovat v odvozenych tridach.

2 podrtrzitka jsou taky jen dohoda programatoru, a rozhodne z toho atributu/metody nedela private:

Kód: [Vybrat]

In [1]: class Foo:
   ...:     def __test(self): print('ahoj')
   ...:

In [2]: Foo()._Foo__test()
ahoj
Jedinej rozdil je, ze se ta funkce jinak jmenuje, a proto ji omylem neprepisu. Pokud ale budu chtit, tak mi nic nebrani si delat co chci:

Kód: [Vybrat]

In [3]: class Bar(Foo):
   ...:     def _Foo__test(self): print('nazdar')
   ...:

In [4]: Bar()._Foo__test()
nazdar

Takze nevim jak ty, ale ja zadne private chovani v tomhle nepozoruju. Jen dalsi hnusny, lec docela prakticky, hack