Qt 4.7.0 tech. preview a Qt Creator 2.0 alpha (diskuse)

[Saljack]

Už aby byl v Qt Creator python s pyside. To by byla teprve pecka.

[xm]

Přesně! Také se toho nemůžu dočkat (předpokládám, že se tak stane, snad to nejsou plané naděje).

I když takový Eric je také velmi kvalitní IDE pro Python/PyQt a rozhodně si na něj nemůžu stěžovat...

[Saljack]

Já myslí, že je to tutová věc jinak by to bylo od Nokie dost hloupé. V Pythnu a Qt vidím budoucnost.

[Jan Šimek]

Každý přece ví, že budoucnost je v Aluminiu.

[progdan]

Kdepak, budoucnost je v heliu!

[thingie]

Ne. Budoucnost je v prdeli. (Pardon.)

[Lol Phirae]

Z prdele vykoukne malá, roztomilá tasemnička, rozhlídne se, zaleze zpátky a ptá se maminky: "Maminko, maminko...co je to modrý, co tak krásně šplouchá? Šssss....šsss..." A maminka říká: "To je moře, holčičko." A tasemnička-holčička se ptá: "Maminko, copak je to kulatý, krásně žlutý, co tak krásně hřeje? A maminka povídá, to je sluníčko, pusinko." A tasemnička se ptá "A proč jsme tady?" Maminka odpovídá: "Protože náš domov je tady, v prdeli..."

[mirec]

No neviem, či sa dá od toho čakať niečo viac ako obyčajný textový editor podporujúci zvýrazňovanie syntaxe pre python. Také doplňovanie pre python je výrazne zložitejšie než pre C++ (a to ešte nehovorím o tom ako ľahko sa dá implementovať do editorov ako vim, kde stačí použiť clang). U pythonu väčšinou nie je možné zistiť akého typu pri behu bude premenná, takže zbohom pokročilé doplňovanie kódu.

[Lukáš Zapletal]

Složitější doplňování? Nespletl sis to s Perlem? Python má velmi čistou syntaxi. To je jeho hlavní přednost.

[mirec]

Nie nemýlim si to. Všetky tieto jazyky sa veľmi ťažko dajú spracovať. Občas keď pozerám cudzí (nekomentovaný) kód musím to vzdať a priznať si, že ani srnka netuší akého je to typu. Jediný (ale nie moc spoľahlivý spôsob) je spustenie, ale ak človek niekde namiesto nejakého objektu dostane None a potrebuje tam niečo iné ale netuší čo tak mu pri pátraní nepomôže nič. Jednoducho preto, že python patrí medzi dynamické typové jazyky. Pre niekoho je to výhoda, pre iného nevýhoda.

[xm]

Jednozančně výhoda :-P Staticky typované jazyky osobně nemůžu vystát. Btw. Python používá duck typing, což je moc pěkný (hezky objektový) druh dynamického typování (a na rozdíl od jazyků jako JavaScript či PHP je Python silně typovaný).

[mirec]

Kým človek nerobí s nezdokumentovaným kódom a môže sa aj rozkrájať a v niektorých špecifických prípadoch to proste padá (vlastná skúsenosť).

[xm]

Já mám vlastní zkušenost jinou (i s nezdokumentovaným kódem, syntaxe Pythonu je velmi dobře přehledná a čtivá a pokud to nepsalo vyloženě nějaké strašné prase, je ten kód de facto samodokumentační - i když samozřejmě kvalitní dokumentaci se to vyrovnat nemůže). Staticky typované jazyky jsem zavrhnul už dávno, i když samozřejmě neříkám že někde své místo nemají (nízkoúrovňový kód)

[mirec]

Nie všetky staticky topované jazyky sú nízkoúrovňové. A mimochodom čítať kód ... nie je to trochu divné? Bežne riešim tým spôsobom, že si pozriem hlavičky a na kód sa pozerám až u časti, ktorú chcem upraviť.

[AHAHA]

Muzes trochu osvetlit v cem je kod Pythonu samodokumentacni? (Oproti stejne dobre napsanemu kodu v libovolnem jinem jazyce)

[xm]

Syntaxe je extrémně přehledná (z mého pohledu) a tak nějak programátory nutí k tomu psát slušně, alespoň taková je moje zkušenost. V cizím pythonním kódu zkrátka většinou nemám problém se dobře vyznat i pokud je nedokumentovaný (na rozdíl od jiných jazyků). Procentuálně jsem se v Pythonu setkal s podstatně menším množstvím prasácky napsaného kódu než v jiných jazycích (porovnávám především s PHP, Perlem, Delphi a pár věcmi v Javě a C++). Rozhodně ale neříkám, že dobře napsaný kód v jiných jazycích nemůže být stejně tak "samodokumentační".

[AHAHA]

Me zarazilo, ze rikas, ze ti nedela problemy cist nedokumentovany kod v Pythonu. Jedna-li se o netrivialni zalezitosti, pak jsem (a predpokladam, ze nejen ja) bez dokumentace a komentaru marny bez ohledu na jazyk Spis bych rekl, ze je to proste o zvyku cist nejaky styl kodu. Python ma vyhodu v tom, ze zpusob zapisu je pevny, takze de facto maji vsichni styl stejny. Jinak se mi ale rigidita syntaxe pythonu v nekterych pripadech nelibi ... ted jsem napriklad psal neco jako:

$result = "";

if($a == 5)	$result .= "A";
if($a > $c)	$result .= "B";
if(strlen($d) == 0)	$result .= "C";

Proste asi deset trivialnich ifu hned za sebou. V tomto pripade je pouziti tohoto zpusobu zapisu naprosto v poradku (jinak je to IMHO parasarna). Pokud se nepletu, v Pythonu bych na to potreboval 3x tolik radku. IMHO se pri diskusich o citelnosti a prehlednosti kodu casto zapomina na to, ze jednim z nejdulezitejsich faktoru je delka kodu. V tomto Python casto ztraci.

[Radek]

result = ""
if a == 5: result += "A";
if a > c : result += "B";
if len(d) == 0: result += "C";

[AHAHA]

Tak to jsem nevedel, ze jde i tohle, omlouvam se.

Nicmene to ukazuje, ze i v pythonu jde prasit

[stativ]

Šablony v C++ jsou podle mého stejná sviňárna pro inteligentní automatické doplňování. Taky nevíš, co ti tam přijde. Tudíž když to jde ošéfovat pro C++, musí to jít i pro python.

[mirec]

Blbosť, u šablón človek vie, aký typ obsahujú v dobe prekladu. Alebo mi niekto chce nahovoriť, že u list<Trieda> zoznam; netuším, čo mi vráti zoznam.begin();? Kedysi boli šablóny pre dopĺňanie horor - pretože sa s nimi dajú robiť rôzne kraviny a proste parsery boli dosť biedne, ale teraz už máme nástroje ako clang, ktoré to hravo zvládnu. Mimochodom ako zistím v kóde def funkcia(nejakyArgument): akého typu je nejakyArgument? Žiaden superiteligentný parser mi nezistí akého typu to bude kým sa program nespustí. Okrem toho nemám istotu, že pri ďalšom spustení bude zase toho istého typu.

[stativ]

Blbosť, u šablón človek vie, aký typ obsahujú v dobe prekladu. Alebo mi niekto chce nahovoriť, že u list<Trieda> zoznam; netuším, čo mi vráti zoznam.begin();? Kedysi boli šablóny pre dopĺňanie horor - pretože sa s nimi dajú robiť rôzne kraviny a proste parsery boli dosť biedne, ale teraz už máme nástroje ako clang, ktoré to hravo zvládnu. Mimochodom ako zistím v kóde def funkcia(nejakyArgument): akého typu je nejakyArgument? Žiaden superiteligentný parser mi nezistí akého typu to bude kým sa program nespustí. Okrem toho nemám istotu, že pri ďalšom spustení bude zase toho istého typu.

Nemyslím, že je to blbost. Když to ví (při běhu) interpret pythonu tak se to určitě dá udělat přinejmenším tak, že by se to spustilo. Navíc vzhledem k duck typingu si nemyslím, že by byl takový problém prostě odfiltrovat to, co danému typu neodpovídá.

[mirec]

Na konci som písal, že spustenie nie je tiež 100%-ným riešením. Program musí prebehnúť aspoň raz cez oblasť, ktorá je pre mňa relevantná a stále tam nie je žiadna istota, že tak budú práve také objekty aké boli počas spustenia. Pri ďalšom spustení tam môže byť niečo úplne iné. A teraz je tu ešte taký zaujímavý problém s implementáciou - zisťovať informácie o všetkých premenných naraz? V celom programe? Existujú mimochodom programy, ktoré majú niekoľko MB zdrojových kódov. Alebo kontrolovať len typy v otvorených súboroch? Čo keď sa niekto rozhodne editovať iný súbor? Stále nútiť programátora spúšťať program znovu a znovu pri každom otvorení súboru? Tak dobre ako u staticky typových jazykov to proste nepôjde a všetko, čo sa snaží podobne fungovať je riešenie, ktoré nikdy nebude 100%-né. Niekomu stačia približné výsledky, iný chce exaktnosť, je to vecou vkusu. Ja napríklad používam vim a žiadne doplňovanie nemám (robím na menších projektoch, pamätám si čo ako funguje).

[stativ]

IMO by to šlo realizovat tak, že by se sestavil strom všech objektů v projektu a co všechno implementují. Z těch by se pak vybraly ty, které by šly použít. Interpretr by pak mohl vyzkoušet ty vybrané, jestli opravdu jdou použít a tím by udělal další filtrování.

[stepo]

Tohle pomerne pekne resi plugin pro Python do Netbeans: pokud chce programator doplnovani kodu v zavislosti na typu promenne, staci pred jejim pouzitim pridat nasledujici komentar:

def foo(param):
    # @type param str
    ...
    ...

Netbeans pak automaticky doplnuje metody u vestavenych typu i vlastnich trid. Problem vsak samozrejme nastava, pokud si dynamicky za behu pridavate nove metody tridy - na to uz je doplnovani kratke. Zalezi tedy na ukaznenosti programatora. (ve smyslu spis "Ceckar" nez rozezny "skriptak)

[Saljack]

Ale blbost, nevím proč by byl problém s tím, že nevíme co to bude za proměnou. Nevidím žádnou souvislost s doplňováním, jenom bezpečnostní, jinak je to v podstatě jedno.

[stepo]

a co treba tohle:

#!/usr/bin/env python

import sys

s = "ahoj"
if len(sys.argv)>1:
    s = 123;

@@@ print s

Muzete s jistotou rict, jakeho typu bude promenna 's' v miste oznacenem '@@@'?

[Saljack]

Cože vždyť to druhé je vnořené tak je to normální celé číslo.

[mirec]

Zaujímavé, u mňa je to string ;)

[Saljack]

To jenom proto, že jsi @@@ smazal a neodsadil, takže to je mimo a proměnná s jako číselná již "neexistuje".

[mirec]

Riadok je označený znakmi @@@, ale to označene nie je myslené ako odsadenie. V takom prípade má premenná typ podľa toho akým spôsobom sa program spustí čo demoštruje práve to, že neexistuje istota, že premenná bude nejakého konkrétneho typu čo je problém pre doplňovanie.

[stativ]

V tom nevidím problém. Prostě to nabídne obě možnosti – jak pro string, tak pro číslo. Ani člověk to nezvládne lépe.

[stativ]

Nebo lépe – doplňování by v tomhle případě bralo v potaz jen průnik toho, co jde dělat i s čísly, i s řetězci.

[stepo]

hmm a co by se melo doplnit v tomhle pripade?

def foo(param):
    param ### tady

Vzdejte to, v Pythonu, vzhledem k jeho podstate, automaticke doplnovani udelat nejde

[stativ]

hmm a co by se melo doplnit v tomhle pripade?

Cokoliv, protože tam cokoliv být může.

[stepo]

Jo, mas pravdu :D vzdavam to

[Saljack]

Já jsem asi mimo, ale když to není odsazení, tak s je lokální proměnná, a když již pracujeme vně tak již neexistuje. Pokud je print odsazeno a je vnořeno v if, tak s je lokální proměná, která překryje string a bude celočíselná, nevidím problém.

[xm]

To je samozřejmě nesmysl, pravdu by si měl, pokud by to byla definice funkce nebo metody. V případě if, for nebo podobných konstrukcí je to jen odsazený blok kódu, ale ne jiný jmenný prostor.

[Lukáš Zapletal]

Qt 4.7 is the first release controlled by a new Qt Continuous Integration system – introducing a new level of control to ensure that the quality of Qt improves with each release.

To mě zarazilo -- vůbec bych nepředpokládal, že CI vůbec nepoužívali (zatím).