Přesun od PHP k Pythonu?

[m.]

chvíli člověk dělá css, pak zase js, převážně ale php

takze jsi holka pro vsechno? CSS+JS ma delat frontendak.

tak vzhledem k tomu, že naše oddělení jsou 2 lidi, tak nic jinýho nezbývá. Je to moje první pracovní příležitost v tomhle oboru, takže jsou to pro mě ohromné zkušenosti, je třeba znát věci v souvislostech ne?

Nahodou podle me dobrej zacatek. Jini sli treba jinou cestou, ale to je jedno. Tak 2 roky, trochu se otrkas, naberes nejake zkusenosti a to je dobry. Jakmile rychlost nabirani zkusenosti zacne klesat (coz byvaji u zacatecniku 2 roky), tak je dobry jit zas dal, treba nekam, kde se i pisou testy :-) nebo neco jineho se dela na trochu vic profi urovni.

[Reklama]

[Kit]

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.

Menší režie než kde? Než v PHP nebo v Pythonu? To bude srovnatelné. Tady se však na nějakou režii nehraje. Je to komponenta jazyka, kterou používáme a nemá smysl vymýšlet něco vlastního. Právě s pomocí takových komponent mají skriptovací jazyky možnost výkonového přiblížení ke kompilovaným jazykům, neboť tyto knihovní funkce bývají kompilovány.

[Kit]

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

Režie s konverzí formátu JSON nikoho nezajímají - nic lepšího pro komunikaci s Javascriptem nemáme. Pokud chceš používat formát XML, YAML nebo třeba Lisp, tak směle do toho, ale s Javascriptem to prostě nebude ono.

Inner classes s OOP moc nesouvisí. Dá se objektově programovat i bez nich a řekl bych, že lépe bez nich.

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

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

Hádka s blbcem je unavná.
1) Není to dohoda programátorů, je to rys a chováni jazyka, který je implementován v interpretu.
2) Není to hack, je to součást promyšleného designu.
3) Nemá to plnit a neplní to bezpečností funkci, to je v introspektivním jazyce nesmyslný požadavek.
4) Smysl toho je jiný, zabránit nechtěnému konfliktu jmen v rozsáhlých programech, což je nezbytně nutné. Bez toho by oop v Pythonu bylo nepoužitelné pro knihovny a rozsáhlejší projekty.
5) Neznal jsi to, meleš teď kraviny a vytváříš mlhu, abys svou neznalost zakryl.
6) I jedno podtržítko má svůj význam, slouží k označování interních součástí modulů, které se pak nenačítají příkazem from modul import *.
7) Ani toto není domluva programátorů nebo hack, ale implementovaný rys jazyka by design.

[ByCzech]

Hádka s blbcem je unavná.
1) Není to dohoda programátorů, je to rys a chováni jazyka, který je implementován v interpretu.
2) Není to hack, je to součást promyšleného designu.
3) Nemá to plnit a neplní to bezpečností funkci, to je v introspektivním jazyce nesmyslný požadavek.
4) Smysl toho je jiný, zabránit nechtěnému konfliktu jmen v rozsáhlých programech, což je nezbytně nutné. Bez toho by oop v Pythonu bylo nepoužitelné pro knihovny a rozsáhlejší projekty.
5) Neznal jsi to, meleš teď kraviny a vytváříš mlhu, abys svou neznalost zakryl.
6) I jedno podtržítko má svůj význam, slouží k označování interních součástí modulů, které se pak nenačítají příkazem from modul import *.
7) Ani toto není domluva programátorů nebo hack, ale implementovaný rys jazyka by design.

+1

Možná by stačilo, kdyby zde přítomní javisti nenutili javovské chování Pythonu. Stejně (blbě) bych mohl argumentovat proti Javě, že nemá chování jako Python a že je to úplně na hlavu. Python to dělá jinak než Java, smiřte se s tím.

[Reklama]

[Kit]

Možná by stačilo, kdyby zde přítomní javisti nenutili javovské chování Pythonu. Stejně (blbě) bych mohl argumentovat proti Javě, že nemá chování jako Python a že je to úplně na hlavu. Python to dělá jinak než Java, smiřte se s tím.

Totéž platí i pro skripty v PHP. Pokud někdo podlehne Javistům a začne v PHP programovat podle nich, tak se mu skripty minimálně 2× prodlouží, znepřehlední a zpomalí. Zcela zbytečně.

[m.]

Hádka s blbcem je unavná.

Tak alespon na necem se shodnem. Z toho budu vychazet.



Prefix __ proste nedela z atributu/funkce private. Python tenhle koncept vubec nema.  Jak jsem ale demonstroval na prikladu, interpretr na to umoznuje sahat z venci a proto to privatni proste neni. A neni to spatne. Podtrzitka slouzi v pythonu k necemu jinemu, napriklad cituju PEP08 a tvuj (4) a (6).

Pouzivat to jako private lze docela dobre, protoze je vysoce pravdepodobne ze to nikdo primo volat nebude. Je to ale hnusny hack.

 
1) a 4) Nefunguje to uplne dobre, zacatecnici se na to nachytaji:

Kód: [Vybrat]

ntc@ntcw /tmp/asd:0:$ cat foo.py
#!/usr/bin/env python3


class Foo:
    def __test(self):
        print('ahoj')

ntc@ntcw /tmp/asd:0:$ cat main.py
#!/usr/bin/env python3

from foo import Foo as Bar


class Foo(Bar):
    def __test(self):
        print('nazdar')


if __name__ == '__main__':
    Foo()._Foo__test()


5) Pletes si me s nekym jinym  ¯\_(ツ)_/¯

[uetoyo]

Hádka s blbcem je unavná.

Tak alespon na necem se shodnem. Z toho budu vychazet.



Prefix __ proste nedela z atributu/funkce private. Python tenhle koncept vubec nema.  Jak jsem ale demonstroval na prikladu, interpretr na to umoznuje sahat z venci a proto to privatni proste neni. A neni to spatne. Podtrzitka slouzi v pythonu k necemu jinemu, napriklad cituju PEP08 a tvuj (4) a (6).

Pouzivat to jako private lze docela dobre, protoze je vysoce pravdepodobne ze to nikdo primo volat nebude. Je to ale hnusny hack.

 
1) a 4) Nefunguje to uplne dobre, zacatecnici se na to nachytaji:

Kód: [Vybrat]

ntc@ntcw /tmp/asd:0:$ cat foo.py
#!/usr/bin/env python3


class Foo:
    def __test(self):
        print('ahoj')

ntc@ntcw /tmp/asd:0:$ cat main.py
#!/usr/bin/env python3

from foo import Foo as Bar


class Foo(Bar):
    def __test(self):
        print('nazdar')


if __name__ == '__main__':
    Foo()._Foo__test()


5) Pletes si me s nekym jinym  ¯\_(ツ)_/¯

“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API...

https://docs.python.org/3/tutorial/classes.html#private-variables

Já sem spokojený a když mi to začne vadit -- což tedy tohle je to nejmenší proč by mi Python vadil, tak tu jsou jiný jazyky. Už fakt ze sebe blbce dělat nemusíš.

"Nefunguje to uplne dobre, zacatecnici se na to nachytaj..."

...protože Python není pro začátečníky 

[Petr]

Hádka s blbcem je unavná.

Tak alespon na necem se shodnem. Z toho budu vychazet.



Prefix __ proste nedela z atributu/funkce private. Python tenhle koncept vubec nema.  Jak jsem ale demonstroval na prikladu, interpretr na to umoznuje sahat z venci a proto to privatni proste neni. A neni to spatne. Podtrzitka slouzi v pythonu k necemu jinemu, napriklad cituju PEP08 a tvuj (4) a (6).

Pouzivat to jako private lze docela dobre, protoze je vysoce pravdepodobne ze to nikdo primo volat nebude. Je to ale hnusny hack.

 
1) a 4) Nefunguje to uplne dobre, zacatecnici se na to nachytaji:

Kód: [Vybrat]

ntc@ntcw /tmp/asd:0:$ cat foo.py
#!/usr/bin/env python3


class Foo:
    def __test(self):
        print('ahoj')

ntc@ntcw /tmp/asd:0:$ cat main.py
#!/usr/bin/env python3

from foo import Foo as Bar


class Foo(Bar):
    def __test(self):
        print('nazdar')


if __name__ == '__main__':
    Foo()._Foo__test()


5) Pletes si me s nekym jinym  ¯\_(ツ)_/¯

Jsi jeste hloupejsi, nez jsem si myslel.

Ani jedno ani dve podtrzitka ti nezabrani, aby ses v pythonu dostal k odkazovanemu objektu, kdyz budes chtit.
Ale dve podtrzitka ti umozni aby ses k nim nedostal nechtene, a omylem si neprepisoval interni zalezitosti, coz by vedlo k zahadnym a tezko odhalitelnym chybam v programu. Jedno podtrzitko tomu nezabrani a je proto vylozene a vyslovne stupidni jim emulovat private, nejde to. Stejne stupidni je ten, kdo neco takoveho tvrdi a prosazuje.  Jedno podtrzitko je urceno pro moduly, nikoliv pro tridy. Pro tridy jsou urceny dve podtrzitka. Slouzi presne k tomu samemu, co vlastnost private, ke schovani internich veci pred potomky. Jestli jsi to ani ted nepochopil, bez delat radsi neco jineho a hlavne tu nesir kraviny.

[todul]

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.

Se vším ostatním souhlasím, ale na API je i Flask overkill. Pokud chci mít jenom jednoduchý middletier, tak je výkonnější třeba Falcon a pokud ani ten nepotřebuju, tak se dá docela dobře psát rovnou ve wsgi.

[BaldSlattery]

Hádka s blbcem je unavná.

Tak alespon na necem se shodnem. Z toho budu vychazet.



Prefix __ proste nedela z atributu/funkce private. Python tenhle koncept vubec nema.  Jak jsem ale demonstroval na prikladu, interpretr na to umoznuje sahat z venci a proto to privatni proste neni. A neni to spatne. Podtrzitka slouzi v pythonu k necemu jinemu, napriklad cituju PEP08 a tvuj (4) a (6).

Pouzivat to jako private lze docela dobre, protoze je vysoce pravdepodobne ze to nikdo primo volat nebude. Je to ale hnusny hack.

 
1) a 4) Nefunguje to uplne dobre, zacatecnici se na to nachytaji:

Kód: [Vybrat]

ntc@ntcw /tmp/asd:0:$ cat foo.py
#!/usr/bin/env python3


class Foo:
    def __test(self):
        print('ahoj')

ntc@ntcw /tmp/asd:0:$ cat main.py
#!/usr/bin/env python3

from foo import Foo as Bar


class Foo(Bar):
    def __test(self):
        print('nazdar')


if __name__ == '__main__':
    Foo()._Foo__test()


5) Pletes si me s nekym jinym  ¯\_(ツ)_/¯

“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API...

https://docs.python.org/3/tutorial/classes.html#private-variables

Já sem spokojený a když mi to začne vadit -- což tedy tohle je to nejmenší proč by mi Python vadil, tak tu jsou jiný jazyky. Už fakt ze sebe blbce dělat nemusíš.

"Nefunguje to uplne dobre, zacatecnici se na to nachytaj..."

...protože Python není pro začátečníky 

No to je zase megablábol...

[uetoyo-nereg]

Hádka s blbcem je unavná.

Tak alespon na necem se shodnem. Z toho budu vychazet.



Prefix __ proste nedela z atributu/funkce private. Python tenhle koncept vubec nema.  Jak jsem ale demonstroval na prikladu, interpretr na to umoznuje sahat z venci a proto to privatni proste neni. A neni to spatne. Podtrzitka slouzi v pythonu k necemu jinemu, napriklad cituju PEP08 a tvuj (4) a (6).

Pouzivat to jako private lze docela dobre, protoze je vysoce pravdepodobne ze to nikdo primo volat nebude. Je to ale hnusny hack.

 
1) a 4) Nefunguje to uplne dobre, zacatecnici se na to nachytaji:

Kód: [Vybrat]

ntc@ntcw /tmp/asd:0:$ cat foo.py
#!/usr/bin/env python3


class Foo:
    def __test(self):
        print('ahoj')

ntc@ntcw /tmp/asd:0:$ cat main.py
#!/usr/bin/env python3

from foo import Foo as Bar


class Foo(Bar):
    def __test(self):
        print('nazdar')


if __name__ == '__main__':
    Foo()._Foo__test()


5) Pletes si me s nekym jinym  ¯\_(ツ)_/¯

“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API...

https://docs.python.org/3/tutorial/classes.html#private-variables

Já sem spokojený a když mi to začne vadit -- což tedy tohle je to nejmenší proč by mi Python vadil, tak tu jsou jiný jazyky. Už fakt ze sebe blbce dělat nemusíš.

"Nefunguje to uplne dobre, zacatecnici se na to nachytaj..."

...protože Python není pro začátečníky 

No to je zase megablábol...

Promiň, ale tvůj styl mi taky nesedí -- neustále tu plevelíš pod různýma nickama -- zboj, geometre apod. Kdybys aspoň napsal s čím nesouhlasíš. Zdar.

[uetoyo]

Python opravdu není, podle mého názoru, pro začátečníky, když se to rozleze na víc než skript. Jestli je to vůběc vhodný jazyk na větší projekty nechávám stranou. Pro začátečníky je snad lepší něco typovaného, co nadává na chyby z blbosti a nepozornosti, hned jak vzniknou.

[David]

Já bych u PHP zůstal a koukal bych se po C#/Java (za mě C#), protože to jsou robustní univerzální platformy. Python je sice líp navrženej než PHP, ale furt je to jen skriptovací jazyk se všema výhodama u nevýhodama.

[Kit]

Já bych u PHP zůstal a koukal bych se po C#/Java (za mě C#), protože to jsou robustní univerzální platformy. Python je sice líp navrženej než PHP, ale furt je to jen skriptovací jazyk se všema výhodama u nevýhodama.

PHP ani Python už dávno nejsou čistě skriptovacími jazyky. Před interpretováním jsou automaticky kompilovány.