Názory k článku
Novinky v jazyce Python 3.0

First!

nechtel, ale zustal

Ne first, ale Third!

Možná bys mohl zkusit kvantifikovat ten čas, který se tím přepisováním ztratí. Já jsem zažil daleko horší martýria kvůli novým verzím knihoven. Pythonu většina těch změn prospěje a noví programátoři a nové projekty holt získají na úkor stávajících. Tomu se říká vývoj.

To vzdy kdyz vyjde nova verze jazyka, prepisujete vsechny projekty se starsi verzi? LOL Bych u Vas nechtel pracovat! Kdyz si predstavim, jak jsem postupne delal v Delphi 3,4,5,6,7, bych asi nedelal nic jinyho nez prepisoval :D

tak pokud delas ve delphi tak ti nezbyde nic jinyho nez prepisovat... protoze to je nekompatibilni i samo se sebou...

Nevím, autore, jak jsi myslel to, že na rozdíl od pohledu není možné z iterátoru dostat znovu tutéž hodnotu. Podle mě jsou oba typy objektů v tomto podobné. dict_keys nepodporuje přístup pomocí indexů a tudíž je to podle mě klasický iterátor, tedy jednou projet a šmytec.

Dobrý den pane Štrauchu,
se zájmem jsem přečetl váš článek a v ničem mě nepřekvapil - přesně jak jsem čekal je psaný horkou jehlou. Nechci vám sahat do svědomí, ale chtěl bych vědět, proč pro vytvoření seznamu z iterátoru neustále používáte konstrukci l=[x for x in iterable]? Není lepší zapsat l=list(iterable)?

Další naprosto fatální chyba - ukázka práce s dictionary (slovníky). Zkoušel jste si onen příklad s for x in d.keys().reverse(): v Pythonu 2.x? Pravděpodobně ne, protože byste zjistil, že on ani ve 2.x nefunguje. Problém je v tom, že metoda seznamu reverse() provádí otočení pořadí v místě a vrací None. A další pro mě velice důležitá věc - můžete mi naznačit případ z praxe, kde jste potřeboval otočit pořadí klíčů z dictionary? Ona dictionary totiž drží klíče neřazené a tudíž není zaručeno, že voláním keys() získate vždy tutéž posloupnost.

Další věcná chyba byla u příkladu s řazením - to řazení, které jste napsal pomocí str.lower() je bez ohledu na velikost písmen!

Další vaše fatální pochybení je u odstavce porovnávajícím bytes a str typy. Zapomněl jste zmínit změnu nejzásadnější - typ bytes je proměnný (mutable) typ, čili ho nemůžete použít jako klíče do slovníku! Typ str je oproti tomu neměnný. Důsledky z toho vyplývající si pravděpodobně domyslíte.

Nehci vám sahat do svědomí, ale mohu se zeptat kolik kódu jste napsal v Pythonu 2.x? A kolik v 3.x?

Omlouvám se všem za "rýpavý" příspěvek, ale takto nepřesný článek hned poránu mě pěkně nadzvedl ze židle. Přeji pěkný den,

Jan Švec

V zasade souhlasim, az na jednu drobnost - podle
http://docs.python.org/dev/3.0/whatsnew/3.0.html
jsou bytes immutable (pokud chcete mutable, je tam bytearray).

Pane Švec,
Ve většině svých poznámek máte pravdu, ale v jedné věci se ve své horlivé kritice mýlíte.
Typ bytes je v pythonu 3.0 neměnitelný (immutable).

zdroj: http://docs.python.org/3.0/whatsnew/3.0.html
Like str, the bytes type is immutable. There is a separate mutable type to hold buffered binary data, bytearray. Nearly all APIs that accept bytes also accept bytearray. The mutable API is based on collections.MutableSequence.

Domnívám se, že i kritiku lze napsat mírnějším tónem a veřejně neponižovat autora za to, že se pokusil o krátké shrnutí.

Souhlasím plně!

Omlouvám se za omyl s bytes, vycházel jsem z Pythonu 3.0a1, kde podle tohoto http://www.artima.com/weblogs/viewpost.jsp?thread=220341 byly bytes ještě mutable.

However, I do want to mention that based upon the feedback for 3.0a1, we've decided to make the 'bytes' type immutable, and create a separate mutable bytes type, 'bytearray'. These two types are mutually compatible, but in the majority of cases you'll be using bytes, not bytearray.

JŠ

Nehledě na to, že horkou jehlou se obvykle šije, nikoli píše... :)

Co pamatuju, tak souvisle jdouci binarni data (tzn. v pameti za sebou) jsou retezec, nebo-li string (viz instrukce MOVSB, apod. v assembleru). Nebo vy kluci z vyssi urovne predelavate nazvoslovi tak, jak se vam hodi?

1. odst: Píšu tam, že to je jedna z možností, Vaše je lepší.

2. odst. Opravdu chyba, špatně jsem tam nakopíroval kód. Opraveno.

3. odst. Opraveno.

4. odst. Píšu o bytes "Cokoli co není unicode, je označováno za data a je reprezentováno typem bytes". Řetězec jsem zmínil až níže a to je taky chyba. Opraveno.

5. odst. V Pythonu 3.0 jsem toho moc nenapsal, není venku dostatečně dlouho a ani se ještě nedostal do mého oblíbeného Gentoo a ani jsem neměl tendenci psát si vlastní ebuild. Všechny příklady jsem zkoušel na final verzi, bohužel někde asi ne dostatečně.

6. Rýpavých příspěvků tu je plno, za to se nemusíte omlouvat :)

Podpora Pythonu 2.6 tu ještě nějaký čas bude

Není to tak, že 2.6 je samostatná řada, která bude podporována (pouze bugfixy) "stále"?

no me tam chybi jedna z veci ktera me asi nejvic nasere a mozna primeje pouzivat vic jiny jazyky - a to je odstraneni "%" pro formatovani stringu..

fakt me prislo super psat veci jako

s = "a = %d, b = %s, c = %d" % (xyz, bflm, psvz)

oproti tomu nove je sice univerzalnejsi, ale bohuzel zbytecne ukecane:

s = "a = {0}, b = {1}, c = {2}".format(xyz, bflm, psvz)

Co?! To akoze z pythonu zmizne "%s %d" % ( "lama", 10 ) ?! Ved to je absolutne zasadna vlastnost ktora sa mi na tom strasne pacila!

Taky mě to štve. Navíc ten způsob s format bude umět asi deset různých způsobů formátování, takže v tom bude jen bordel :(

To ma tiez dost znepokojuje, pretoze ja Python pouzivam hlavne na reporty z databazy a generovanie zdrojoveho kodu XML alebo COBOL a vsade hodne pouzivam formatovanie pomocou operatora [b]%[/b].

Python 3.0 som si este nenaistaloval, lebo uprimne povedane mam z toho trochu neprijemny pocit co mi to vyhlasi ked v nom skusim spustit jeden zo svojich programov?

Zaujimalo by ma ci konventor 2to3 dokaze bez problemov prekonvertovat prikazy typu
[code]
print "foo='%s' bar='%s'" % (foo, bar)
[/code]
na
[code]
print("foo='{0}' bar='{1}'".format(foo, bar))
[/code]
alebo si take nieco musim napisat sam?
Mate s tym niekto skusenost?

Ospravedlnujem sa za formatovanie. Vacsinou pisem na www.tek-tips.com a myslel som, ze root podporuje tiez TGML
Mal som asi nejaky skrat :-) , takze oprava:

To ma tiez dost znepokojuje, pretoze ja Python pouzivam hlavne na reporty z databazy a generovanie zdrojoveho kodu XML alebo COBOL a vsade hodne pouzivam formatovanie pomocou operatora %.

Python 3.0 som si este nenaistaloval, lebo uprimne povedane mam z toho trochu neprijemny pocit co mi to vyhlasi ked v nom skusim spustit jeden zo svojich programov? Zaujimalo by ma ci konventor 2to3 dokaze bez problemov prekonvertovat prikazy typu

print "foo='%s' bar='%s'" % (foo, bar)

na

print("foo='{0}' bar='{1}'".format(foo, bar))

alebo si take nieco musim napisat sam? Mate s tym niekto skusenost?

Kdysi jsme rikavali "fyzika naucis programovat v jakemkoli jazyce, jen se musi jmenovat fortran" Python(y) je sikovny jazyk. Co mu ale chybi je moznost, alespon volitelna, pro praci s bloky kodu. Kdybych nepouzival konstrukce typu for: ... #endfor tak se v nem pri kopirovani kusu kodu ztratim :)

Bloky kódu lze nahradit funkcemi

prosim vysvetlit.. mozna to chapu, ale to by znamenalo takovou prasarnu ze si tuhle moznost odmitam pripustit..

co znamena "prace s bloky kodu" ?!?!

Ja tomu rozumim tak, ze v Pythonu se bloky definuji tim, ze se odsadi kod. V jinych jazycich neni formatovani zdrojaku kriticke a bloky se definuji nejakou konstrukci:

Pascal: begin, end
C/C++/AWK/Perl: slozene zavorky {}
Bash: while..done, if..fi, atd
Fortran: for:..#endfor, atd

Pokud nejste na Python zvykly, je definice bloku odsazovanim nezvykla a matouci. Osobne se mi to zda jako blby napad... Python znam malo, nepouzivam.

Mě to naopak přijde jako super řešení, protože ve většině curly bracket jazyků se stejně ty bloky kódu kvůli přehlednosti odsazují.

Jenze se muze nechat automaticky odsadit podle tech slozenych zavorek (nebo jineho explicitniho popisu struktury), coz se hodi obzvlast pri kopirovani kodu.

ja jsem prave rad za praci s bloky prave pomoci odsazeni
+ je to rychle
+ je to prehledne
+ uniformni kod (programator nemuze psat jako prase, nebo pouzivat svuj "unikatni" styl, takze orientace v cizim kodu je rychlejsi)

zavorky v C jeste preziju (nemusim v C tolik programovat)

ale za begin end bych vrazdil a jazyky typu pascal by lidi nemeli poustet kamkoliv dal nez z ucebnic (nebo pak vznikaji podobne hruzy jako visual basic etc.)

A co je hrozneho na begin a end?

Je to méně přehledné. Ty závorky se od ostatního kódu alespoň výrazně odlišují a i v jednodušších editorech to vysvicuje, odkud pokud sahá ten blok.

jenze kdyz pisete konstrukce typu end while / end if apod. tak aspon poznate, co se ukoncuje,
zatimco u } nic nepoznate

Zrovna v Pascalu u všeho bylo begin / end (žádné fi, done ani nic jiného závislého na počáteční podmínce), tak se nepoznalo taky nic, nebo vlastně kvůli nevysvicování souvisejících závorek ještě míň.

Treba v Ade se to ale pozna.

Pokud mate kratsi blok kodu, tak je ukoncujici "end if" a podobne vyrazy docela zbytecny. Pokud je kod bloku delsi tak prece neni problem na jeho konec pripsat komentar stylu #end if nebo #end while a tak dale. Begin a end je zlo nejvetsi, je to neprehledne, u zavorek {} clovek hned na prvni pohled vidi odkud kam ten blok saha. Zato begin a end snadno splyne s kodem pokud je za sebou nekolik kratsich prikazu. Taky to vypisovani je zbytecne zdlouhavy. Celkove mam z begin a end husi kuzi :-/

A co teprve, když někdo na začátek Céčkového zdrojáku napíše

#define begin {
#define end }

a potom píše v C-Pascalu

int main()
begin
    printf("Hello world!\n");
    return 0;
end

Zvlastni, ze se to zda jako blby napad vzdycky tem, co to nepouzivaji. V praxi je to totiz citelnejsi.

Doporucuji to zkusit, protoze v praxi zjistite, ze to neni vubec problem.

Jinak, pouzivat nejake #end a take neni dobry napad. Prekladac to nekontroluje, takze si clovek pak IMHO snaz nabehne.

Tak jste to asi pochopil dobře, opravdu se nejspíš jedná o kopírování kusů kódu z jednoho místa na druhé. :-)
Ať žije Hackles!

Díky těmto změnám brzy dojde k situaci, kdy nebude existovat žádný větší pořádně odladěný a léty prověřený program v Pythonu a pojede se skoro od nuly.

Podpora starší verze také nebude věčně, a hlavně jí věčně nebudou podporovat autoři knihoven.

Já tohle nevidím jako pokrok, protože jazyk, který po 17 letech existence není schopen zachovat zpětnou kompatibilitu, a je nucen syntaxi totálně rozkopat, je důkaz neserióznosti Pythonu. Pokud chtěl Python rozrývat syntaxi, měl to dělat první léta svého fungování, jazyk, který kašle na kompatibilitu poté co 17 let existuje dává za signál jenom jediné: nesvěřujte mu nic důležitého.

Představte si, že by toto třeba udělalo Céčko, nebo unixový shell. Najednou by se někdo rozhodl, že Céčko je třeba nekompatibilně překopat, a všech C programy včetně linuxového kernelu, a všech základních služebních programů je nutné přepsat a předělat. Myslím, že by MS slavil, protože Linux by z nich dlouhá léta nevyšel.

zapomněl jsem dopsat konec: protože Linux by z nich dlouhá léta nevyšel z chyb, nespolehlivosti a pádů, než by ty změny odladil.

Nemaluj čerta na zeď. Python nebyl NUCEN totálně překopat syntaxi, jeho autoři prostě měli pocit, že design už poněkud zastaral. Rozhodně bych nechtěl, aby z Pythonu vznikla přeplácaná prasárna typu C++ nebo naopak kdyby se jazyk přestal vyvíjet, pokud vývoj pokročí kupředu.

Chtěl bych se zeptat, jestli v případě popsaných změn existuje automatický nástroj pro převod zdrojáků do Pythonu 3.0. Kde nelze převod provést automaticky, čekal bych warning s poznámkou.

Existuje, jmenuje se 2to3

Pěkné, děkuji za info. Považuji za špatné, když převaděče neexistují.