Python - circular importy v type hintech

[dustin]

Myslím, že po pár příspěvcích je jasné, že to bylo asi myšleno jen jako vtip. Na skriptíky pro admina je to jazyk velmi dobrý, ale na vývoj to není.

Vidím to tak nějak stejně. Skriptíky se v něm píšou perfektně, není potřeba žádný build systém, mohu krokovat, ladit, paráda. Ale na složitější projekt mi to nejpřijde dostatečně robustní. I když v poslední době se to posouvá (typelib, abc pro abstraktní metody/třídy, atd.), jen to chce ještě pár verzí a jejich dobrou podporu v IDE (i když např. pycharm je v podpoře beta vlastností docela dopředu, stejně jako jeho sestra Idea v javě).

[Reklama]

[gll]

Nejde o javu, ale o typy. Nedovedu si představit, jak efektivně vyvíjet projekt už o pár desítkách tříd bez typů. Očividně to pálí spoustu lidí, když v poslední době vzniklo několik na sebe navazujících PEPů, které se to nějakým způsobem snaží řešit.

Cirkulárním závislostem se lze většinou vyhnout jiným rozvržením kódu. Vůbec není nutné mít každou třídu ve zvláštním souboru. To je omezení Javy.

[dustin]

Rozdělení tříd do více souborů má spoustu praktických výhod - snáze se hledají, je snazší si otevřít třídy ve více panelech vedle sebe v IDE (mám vždy dva editační panely), soubory jsou krátké a přehledné. Snáze se také v rámci jednoho souboru vyhledává/nahrazuje - je to v rámci jedné třídy. Rovněž commity v GITu jsou přehlednější, protože už z výpisu změněných souborů v diffu vidím, jakých tříd se týkal. IMO je soubor na public třídu užitečný způsob.

V některých souborech mám několik spolu úzce souvisejících tříd, ale jen pokud jsou krátké, většinou jen pomocná DTO. Navíc třídy v jednom souboru musí jít ve správném pořadí, jak jsou postupně definované - i tak musí být typehinty uvedené jako stringy v apostrofech. Když se na to zapomene - opět se to zjistí až při prvním spuštění, IDE nic nezahlásí, protože třídu zná, zatímco interpret ne.

[dustin]

Ještě jsem zapomněl na zásadní přínos rozdělení do souborů - zatím jsem nepotkal IDE, které by nabízelo commit jednotlivých hunků v souboru, ale vždy jeho všechny změny. Takže granularita commitu přes IDE je soubor. Velice často dochází k tomu, že se smíchají dvě změny, které se ale týkají různých tříd. U malých souborů je v IDE commit snadný. Kdybych měl všechny třídy v jednom souboru (zrovna jednu takovou externí knihovnu používám), bylo by commitování přes interaktivní add -i o dost pracnější (nebo bych musel používat nějaký externí GUI nástroj).

[gll]

Ještě jsem zapomněl na zásadní přínos rozdělení do souborů - zatím jsem nepotkal IDE, které by nabízelo commit jednotlivých hunků v souboru, ale vždy jeho všechny změny. Takže granularita commitu přes IDE je soubor. Velice často dochází k tomu, že se smíchají dvě změny, které se ale týkají různých tříd. U malých souborů je v IDE commit snadný. Kdybych měl všechny třídy v jednom souboru (zrovna jednu takovou externí knihovnu používám), bylo by commitování přes interaktivní add -i o dost pracnější (nebo bych musel používat nějaký externí GUI nástroj).

emacs+magit to umí.

[Reklama]

[dustin]

To je dobře. Již roky doufám, že IntelliJ hunky do svého portfolia doplní, v jejich IDE by se sakra hodily. Ale i tak je daleko rychlejší vybrat celý soubor, než označovat hunky diffu. Občas to dělám v terminálu, nic moc. A proto zůstanu u hodně souborů s minimální velikostí, než doufat, že jsem na nějaký hunk do commitu nezapomněl.

[gll]

To je dobře. Již roky doufám, že IntelliJ hunky do svého portfolia doplní, v jejich IDE by se sakra hodily. Ale i tak je daleko rychlejší vybrat celý soubor, než označovat hunky diffu. Občas to dělám v terminálu, nic moc. A proto zůstanu u hodně souborů s minimální velikostí, než doufat, že jsem na nějaký hunk do commitu nezapomněl.

v PyCharmu už to bude brzy https://youtrack.jetbrains.com/issue/IDEA-63201

tohle by neměl být problém dopsat, kdyby byl git plugin spravován komunitou, tak už by to někdo dávno udělal.

[dustin]

Výborně, díky. Mohu jen citovat poslední příspěvek: +1 After 7 years, it is happening!