Můj názor:
- Odsazování (bez závorek) rozhodně zvyšuje čitelnost. To je jedna z věcí, která se mi na něm opravdu moc líbí.
- Python je debilní, a na větší projekty bych se mu vyhnul, protože nemá typy a má GIL.
+1
Plus nemožnost refactoringu z toho dělá jazyk maximálně na skriptíky.
Odkud pořád tihle tydýti s tímhle nesmyslem vylízají? Vyvrátí se jim to v diskuzi a oni po čase přijdou s touhle kravinou znovu. Kdyby si aspoň tu diskuzi přečetli pořádně a nedělali ze sebe hlupáky! 
Tyhle "kraviny" a "nesmysly" řeším už pár let pořád dokola, když dělám na svých domácích projektech. Zrovna včera jsem vytahoval třídu do samostatného souboru. Konkrétně třídu Handler z tohoto zdrojáku (
https://github.com/mopidy/mopidy/blob/develop/mopidy/audio/actor.py#L177 - předělávám to pro své účely ) To, co je v javě u vnitřní třídy práce na pár sekund (F6 Move v idee), jsem v Pycharmu dělal možná půl hodiny. Společné struktury mezi třídami jsem musel vytáhnout úplně jinam, jinak se cyklické importy nedaly vyřešit.
Samozřejmě doplňuji všude typehinty - opět po spuštění cyklické importy. OK, dám do podmínky if TYPE_CHECKING - ejhle interpretu se nelíbí dvojtečkové typehinty - nezná import, který je jen pro IDE. Proč mu to chybí netuším, když s nimi stejně nepracuje. Takže pěkně názvy tříd do apostrofů, aby to IDE pochopilo a interpret neřval, stringy v typehintech neřeší. Super práce pokus/omyl.
Původní proměnné byly protected (audio._playbin) a protože byl Handler v jednom souboru s Audio, nijak mu to nevadilo. Po vytažení už na ně samozřejmě nevidí - další runtime chyba. Opět v javě nehrozí, IDE to rovnou zkontroluje a nedovolí takový refaktoring, příp. rovnou změní viditelnost na public. Nevadí, přejmenuji z _playbin na playbin. Ale chyba - kde proměnná audio nemá uvedený typehint na Audio, tam nepřejmenuje. Takže v původním souboru je audio.playbin, ve druhém zůstává audio._playbin. Dozvím se po spuštění. Kdybych však měl typehint včas, věděl by, že proměnná audio v Handleru je třídy Audio, jejíž field _playbin zrovna přejmenovávám, a přejmenoval by mi i ty v Handleru. Jenže jsem bohužel zvolil opačný postup...
Ještě mohu při přejmenování zaškrtnout i "search in comments and strings". Pak by to přejmenoval OK, ovšem úplně všude, což je samozřejmě zcela špatně. Obzvláště při dodržování zde tolik propagovaných krátkých stručných názvů je to chuťovka - třeba přejmenovat close jedné třídy na closeFile zmrví celý echt pythonní zdroják dle PEPxxx s úspornými názvy. To je přesně důvod, proč v pythonu jednoslovné metody (tedy jedno sloveso) nepoužívám takřka vůbec, vše se snažím mít jedinečné, aby to šlo dohledat a nemotaly se tam nijak nesouvisející výskyty stejného slova.
Když důsledně všude používám typehinty, IDE dává přejmenování a přesuny jakžtakž spolehlivě a nemusím po každé změně půl hodiny opravovat nesmysly. Bohužel jsem nepřišel třeba na to, jak například typehintem přetypovat stávající proměnnou jinak, než
def method(param: Message)-> None:
if isinstance(param, SpecialMessage):
param = param # type: SpecialMessage
param.metoda_definovana_ve_special_message()Konkrétní ukázku mám třeba
https://github.com/pavhofman/aio/blob/master/sources/treesource.py#L41 . Ví někdo, jak to udělat jednodušeji? Moc rád se poučím.
Metody v API knihoven bez typehintů začínají kontrolou datových typů, např.
https://github.com/dddomodossola/remi/blob/master/remi/gui.py#L465 nebo dokonce
https://github.com/dddomodossola/remi/blob/master/remi/gui.py#L1497 . To je přece peklo...
Typehinty jsou v pythonu teprve v posledních verzích, sláva bohu za to. Bohužel bude ještě chvíli trvat, než je IDE začnou pořádně používat. Třeba Generic + TypeVar - pro přehlednost samozřejmě používám, ale typehint se ani v nejnovějším PyCharmu stejně nechytá, konkrétní hodnotu to stejně nepozná (např.
https://github.com/pavhofman/aio/blob/master/sources/treesource.py#L22 vs. jeho vzdálený potomek
https://github.com/pavhofman/aio/blob/master/sources/filesource.py#L23 či
https://github.com/pavhofman/aio/blob/master/sources/cdsource.py#L26 ).
Tohle není příjemné programování, na jaké jsem zvyklý z javy. Na psaní skriptu je to rychlé, ale zpětně docela lituji, že jsem do pythonu šel. Přepisovat už se mi to nechce, tak skřípu zuby a doufám, že při stávajícím tempu vývoje bude za pár let o kus dál a budu si moci užívat pohody generátorů, práce se slovníky, mixinů, knihoven na úplně vše, tedy toho, co mě na pythonu baví.