Vlákno názorů k článku
Red Hat nechce Mono v RHEL

Otázka je jak je to s pythonem. Zda je to náhrada, protože další verze python 3000 má být nekompatibilní se současným pythonem a to rozhodně není znak serióznosti a něčeho, co by jej opravňovalo pro podniková a vážná řešení.

Ač nemám příliš v lásce Javu, zdá se mi, že tam takové kejkle nejsou, tedy že jak Java, tak byte kód je standardizován a nepamatuji se, že by někdo musel rozsáhle přepisovat zdrojáky jen proto, že vyšla další verze Javy. Ale možná se mýlím.

Ale Python deklaruje, že nezachová zpětnou kompatibilitu a to je podle mě i signál do budoucna, že mu nelze svěřit větší věci, protože nechrání investice do existujícího kódu.

Píšu to proto, že sám jsem hodně napsal v Pythonu, je to skvělý jazyk, ale přemýšlím o jiném právě z tohoto důvodu. Seriózní jazyk by měl věci měnit jen v odůvodněných případech a jinak raději používat zaklínací formule obsoleted, deprecated a warning, ale dál se moc neodvažovat.

Python 3000 není další verze Pythonu. O Pythonu 3000 se mluví již léta. Vždycky když vývojáři dojdou na to, že něco implementovali blbě, že zvolili nepříliš šťastnou koncepci, ale nemohou to opravit právě z důvodu zachování zpětné kompatibility, tak řeknou, že to opraví/odstraní ve verzi 3000, tedy Pythonu 3.0, který nebude zpětně kompatibilní, jak napovídá změna major verze. Tyto záležitosti se evidují a možná jednou Python 3.0 opravdu vznikne, ale zatím se na něm nedělá a vyvíjí se už po řadu let řada 2.x. I kdyby k tomu jednou došlo, nebude tu žádný problém paralelně provozovat verzi 2.x a 3.x současně, jako se dodnes může provozovat současně řada 1.x a 2.x, má-li někdo tu potřebu.

není problém provozovat verzi 2.x a 3.x současně? jak dlouho to nebude problém? a budou všichni autoři knihoven pro python udržovat verze pro 2.x a 3.x? už teď je problém, protože verze pro 2.4 nechodí třeba pro 2.5. takže opravdu to nebude problém? opravdu není problém provozovat 1.x verzi pythonu?

blbě se navrhne vždycky něco, ale to není důvod k porušení zpětné kompatiblity, ale k tomu označit danou konstrukci jako deprecated, ale je potřeba jí tam nechat pro starší kód. navíc změny navrhované v pythonu a porušující zpětnou kompatiblitu jsou takové ptákoviny, že je těžko obhájíte jinak, než rozmarem

reálně to nevídím tak bez problému jak uvádíte

Provozovat soucasne python 2.x a 3.x je problem, protoze python 3.x neexistuje, to da rozum. Provozovat soucasne 2.x a 1.x problem skutecne neni, v dobe vzniku pythonu 2.0 to byl na linuxu standardni stav.

Presne tak to Python dela, zastarale veci oznacuj jako deprecated a ponechva je pro zpetnou kompatibilitu po nekolik let. Pokud by mel snad jedno vzniknout nekomatibilni python, tak proc to nevzit od podlahy? Je naopak v poradku, ze se pamatuje i na banality, neni to rozmar, ale dukladnost. Tyto banality nejsou duvodem pro vytvoreni nekompatibilni verze. Zadny takovy duvod dnes neexistuje. Kdyby se objevil, svezou se s tim i ostatni zmeny. Divim se, ze mate tak velky problem pochopit tak jednoduchou vec. Ostatne, kdyz se takovy duvod objevil u C a vzniklo C++, tak to taky nikomu nevadilo, C se klidne udrzovalo zakonzervovanw pri zivote dal a rozvijelo se C++.

Ten oddůvodněný případ mezi 1.x a 2.x bylo objevení se UNICODE a jeho podpora jako nového datového typu.

A mimochodem, Python 2.0 vyšel v roce 2000, od toho Python 3000 :-). Jestli někdy dojde ke vzniku Pythonu 3.0, bude to nepochybně dobře oddůvodněné. Vývojáři Pythonu na zpětnou kompatibilitu řádně dbají a na různé změny dlouhodobě (po několik verzí pythonu) upozorňují (deprecate warning).

vývojáři pythonu dbají na zpětnou kompatibilitu, ale veřejně deklarují, že nebude zachována. to je celé. prostě všechny jazyky, které dlouhodobě drží na špici si nikdy neodvážily hrubě porušit zpětnou kompatibilitu. zkuste v javě deklarovat, že další verze javy nebude mít kompatibilní syntaxi s předchozí javou a všichni vás vyštípou. zkuste prohlásit, že bash v příští verzi nebude kompatibilní se současnou verzí a bude nutné všechny shellovské skripty přepsat a budete si muset připravit ústupovou cestu a raději chodit kanálama. zkuste prosadit, že příští verze jazyka C nebude umět přeložit milióny existujících programů v C a nikdo vás nebude brát vážně. totéž pro c++, adu, fortran, cobol, ... prostě všechny jazyky, ve kterých se naprogramovaly obrovské projekty, a ve kterých se nikdo nebojí dělat si NIKDY nedovolí ani POMYSLET NA TO, že by některá další verze nebyla zpětně kompatibilní, natož to veřejně prohlásit jako GvR. tohle je rozdíl mezi seriózním jazykem a ostatními. jazyk, který nezajistí možnost v jakékoli další verzi přeložit a používat již existující kód deklaruje, že nechrání investice do něj vložené.

Tak zrovna Java zrušila (kromě jiných kotrmelců) "private protected" metody a co se stalo? Nic. Je možné v nejnovější specifikaci jazyka C používat K&R deklaraci parametrů? Pokud ne, vadí to někomu, pokud ano, používá to dneska někdo?

K čemu tohle plašení? Až (jestli) se vývojáři Pythonu rozhoupou a začnou pracovat na projektu "Python 3000", určitě jedna z věcí, kterou budou řešit jako první, bude jak zajistit plynulý a pokud možno bezbolestný přechod stávajících aplikací na Python 3000.

Fáze 1: implementovat do stávající verze vlastnosti, které ve verzi "3000" budou klíčové a potřebné k přechodu

Fáze 2: označit jako zastaralé ty vlastnosti, které z verze "3000" budou vyloučeny

Fáze 3: nabídnout nástroj, který provede automatický převod méně komplikovaných konstrukcí a označí problematické pasáže, které by neměl být problém v rozumně navržené aplikaci přepsat.

Fáze 4: vypustit Python 3000 pro nadšence

Fáze 5: označit Python 3000 za hlavní vývojovou platformu

Tento přechod může klidně trvat hodně let (kde máme Perl 6?). Za tu dobu hromada projektů morálně zastará. Nechci se bavit o tom, jestli všechny změny v Pythonu 3000 (který ještě nikdo neviděl, ale za sebe říkám: pokud je něco v Pythonu skutečně špatné, přepište to.

znáte kompilátor jazyka C, který neumí přeložit K&R metody? já ne a to jich znám desítky od jednočipů po ...

vývojáři pythonu 3000 už vygenerovali desítky dokumentů jak to bude a prezentovali, že nebude zajištěna kompatibilita

ad fáze 3: neznám žádný nástroj, který by v praxi 100% fungoval bez lidského zásahu. i Vy píšete, že pouze označí, nikoli přegeneruje. až budete mít sw s pár milióny řádky, který léta ladíte a pak ho pomocí nástroje budete měsíc přepisovat a samozřejmě tam zanesete takto nové chyby, takže bude nestabilní jak na začátku, znovu projít náročnými testy atd.. - to je báječné, podnikoví ekonomové se mohou rozplynout blahem a všichni budou š%tastni děkovat GvR :-(

ten přechod může trvat řadu let, ale důležité je, že se připravuje, a že se nehodlá nikdo zpětnou kompatiblitou vážněji zabývat. z toho jasné vyplývá, že investice do kódu v pythonu nehodlají vývojáři ochránit a je to signál pro ty, kdo potřebují vyvíjet větší aplikace, které se budou řadu let udržovat - a ten signál je, že python není vhodný. už jen to, že se o tom vážně uvažuje, a že kompatibilitu nikdo moc neřeší je důležitý. chytrý poslouchá teď, hloupý pak řeší až nastanou problémy.

OK. Co sa tyka spatnej kompatibility je C-ko nekorunovanym kralom, ale vsetky ostatne jazyky kompatibilitu z casu na cas neriesia.

VŠECHNY jazyky, které jsou stálicemi jí řeší - C, C++, Ada, Fortran, Cobol, ... tohle všechno je stále zpětně kompatibliní i desítky let u starších jazyků

V kompatibilitě C u C99 rozbili dost významnou věc --- definovali, že kompilátor může přehazovat přístupy na pointery různých typů a rozbili tím dost programů.

(problém je tu mnohem zákeřnější než se změněnou syntaxí --- tady ne, že se to nezkompiluje, ale zkompiluje se to a pak to dělá něco jiného v závisloti na verzi kompilátoru nebo optimalizacích).

... a původní K&R C tuším dovolovalo sčítat pointery nebo odčítat pointery různých typů (nevím, co mělo být výsledek; narazil jsem na to při pokusu o kompilaci nějakých programů z originálního unixu).

Další věc, co odstranili, byl soubor <varargs.h>, kterým se dělaly funkce s proměnným počtem argumentů s K&R prototypy. Odstranili to nejspíš z důvodu, že je to na architekturách, co mají argumenty v registech, neimplementovatelné.

Nějak jste zapoměl na Javu? Nakonec .NET 1.0 rovněž není kompatibilní s 2.0, některé věci je nutno přepsat a tak dále. Taky historie VB od Microsoftu je velmi pohnutá. A co ASP? Nebo třeba Access, tam se taky musely programy přepisovat. A co na to podnikoví ekonomové?

Vývojáři Pythonu na to své uživatele připravují s předstihem spousty let (dnes minimálně pěti, aniž by se na Pythonu 3000 ještě začalo pracovat, či se jen vědělo, zda vůbec vznikne. Jen se shromažďují požadavky pro případ vzniku nekompatibilní verze).

Jak už jsem napsal, žádné přepisování není třeba, staré aplikace poběží stále na interpretu 2.x.

To je FUD, zpětnou kompatibilitou se vývojáři Pythonu zabývají mimořádně poctivě. Už řadu let dopředu dávají najevo, co by se mohlo změnit, kdyby mělo k nějaké takové verzi dojít. Ostatní vás z čista jána postaví před hotovou věc. U Pythonu víte již dnes co je nemoderní a co možná za několik let nebude podporováno, pokud z uddůvodněných případů ke vzniku takové verze dojde, přičemž staré aplikace bude moci pořád provozovat ve staré verzi, upgrade na 3000 nebude povinný. Chytrý člověk není hloupý a tmář jako vy :-).

Odpověď viz jiný příspěvek. VB, ASP a nejmě Access řešit nebudu. Protože tohle je jiný případ. Nemluvím o tom, že vše je standartizované.

Žádné přepisování ZATÍM není třeba, ale deklaruje se, že vývojáři připustí, že to BUDE TŘEBA.

To, že vývojáři Pythonu dávají najevo, že to bude nekompatibilní je hezká věc, ale důležitý je i fakt, že nekompatibilitu vůbec připustí bez závažného důvodu. A závažný důvod jen takový, že to nelze ani při 100% snaze udělat jinak. Stará verze nebude existovat na věky věků a nikdo vám ani interpretr, ani tisíce knihoven nebude udržovat funkční pro starou verzi, postupně to začne být nepoužitelné. Díky za toho tmáře, myslím si, že každý člověk by měl o Pythonu vědět, že když v něm udělá větší projekt, že bude mít potencionálně tyto potíže.

A neslo by to udelat nejak tak aby Python 2000 program mohl volat Python 3000 knihovnu ?

V zásadě je to podle mě možné bez větších problémů - prostě se přeloží moduly z Python 2.x a Pythonu 3000 do společného bytecode a tam už ty rozdíly nemusí být podstatné. Pokud například pro celočíselné dělení bude v Pythonu 3000 (a neřešme teď, jestli nějaký bude nebo ne), přeloží se 3 / 2 v Pythonu 2.x do stejné instrukce (např. INTDIV) jako 3 // 2 v Pythonu 3000. Lambda může být nahražena normální funkcí (na úrovni překladače), range() ze stávajícího Pythonu se dá převést na list(range()). Teď mě ale napadá, že by mohl být problém s klasickými třídami, které mají poněkud jiné chování než třídy nového stylu - tahle rozpolcenost by podle mě z Pythonu měla zmizet každopádně.

Pak je samozřejmě možné zachovat bytecode a interní podporu klasických tříd (a možná i jiných vlastností, pokud by bylo třeba) v novém interpreteru dál, akorát by překlad do .pyc nebo .pyo musel být dělán samostatným překladačem. Takto by bylo možné zachovat možnost současného běhu 2.x a 3000 modulů libovolnou dobu. Otázkou je, jestli by se to vyplatilo. Vzpomeňme si na nedávný pokřik ohledně @ syntaxe pro dekorátory, která udělala problémy vývojářům projektů ipython a leo. Bylo to trochu nepříjemné, ale nic strašného se nestalo.

To zalezi na tom, z jakeho duvodu by treti rada vznikla, je spis pravdepodobnejsi ze ne, protoze u pythonu se moduly pisi pro konkretni verzi. Ono je to logicke, pokud mdul vyuziva novych vlastnosti, tezko pujde pouzit se starym interpretem, ktery je neumi.

znáte kompilátor jazyka C, který neumí přeložit K&R metody? já ne a to jich znám desítky od jednočipů po ... Nevím, nezjišťoval jsem to. Tvrdím ale, že kdyby od června 2008 všechny najednou přestaly tyhle metody překládat, naprosto nic hrozného by se nestalo. až budete mít sw s pár milióny řádky, který léta ladíte a pak ho pomocí nástroje budete měsíc přepisovat a samozřejmě tam zanesete takto nové chyby, takže bude nestabilní jak na začátku, znovu projít náročnými testy atd.. A kolik programů s pár milióny řádky v Pythonu máte Vy? Pro zajímavost, v Zope 2.10 je něco přes půl miliónu řádků v Pythonu. ten přechod může trvat řadu let, ale důležité je, že se připravuje, a že se nehodlá nikdo zpětnou kompatiblitou vážněji zabývat. To snad nikdo netvrdil, že se problémem nebude vážně zabývat. z toho jasné vyplývá, že investice do kódu v pythonu nehodlají vývojáři ochránit a je to signál pro ty, kdo potřebují vyvíjet větší aplikace, které se budou řadu let udržovat - a ten signál je, že python není vhodný. Kdo ochránil investice vývojářů, kterým nechodí aplikace pod Windows Vista? Kdo ochrání Vaše investice, až vyjdou nové Windows a Microsoft se rozhodne nějaké rozhraní přestat podporovat? Kdo ochránil investice vývojářů webu, pokud zjistili, že IE7 nevykresluje dobře stránky? Kdo ochrání Vaše investice do kódu v Javě, pokud zkrachuje Sun? O jakých zárukách se bavíme? Jaké REÁLNÉ problémy se řeší? chytrý poslouchá teď, hloupý pak řeší až nastanou problémy. Takovýto typ "argumentace" neberu.

až by přestal kompilátor C překládat K&R metody, pak by mnoho kódu nešlo přeložit. vy si myslíte, že by se nic hrozného nestalo, ale naštěstí zodpovědní lidé vidí reálněji, než vy.

neznám programy s milióny řádky v pythonu, protože takové vznikají pouze v seriózních jazycích, které nemění zpětnou kompatibilitu. v jiných je to neúnosné.

ohledně Windows vista - které KONKRÉTNÍ aplikace napsané přesně podle dokumentace Microsoftu nebude fungovat? pokud jsou programátoři prasata a používají nedokumentovaná rozhraní, nebo rozhraní pro drivery, které jsou proměnlivé, pak samozřejmě bude problém. příklad takových prasáckých aplikací je třeba cygwin, který bez skrupulí používá nedokumentové API Windows. jaké KONKRÉTNÍ rozhraní nebude podporovat?

co se týká IE7, žádný browser nezaručuje stejné vykreslování stránek, viz W3C standardy.

až zkrachuje Sun, tak Java stále bude žít. jaké KONKRÉTNÍ problémy v investicích do vašeho kódu nastanou, pokud zkrachuje Sun?

až by přestal kompilátor C překládat K&R metody, pak by mnoho kódu nešlo přeložit.

Veškerý tento kód by se dal poměrně snadno převést do přeložitelné podoby. Velice jednoduše by se dalo ověřit, že přeložený program bude funkčně ekvivalentní.

vy si myslíte, že by se nic hrozného nestalo, ale naštěstí zodpovědní lidé vidí reálněji, než vy.

Mohl byste už konečně zanechat toho bullyingu?! Nestačilo Vám napsat jednou, že na takovýto způsob argumentace nejsem zvědavý?!

které KONKRÉTNÍ aplikace napsané přesně podle dokumentace Microsoftu nebude fungovat?

Například některé aplikace od Microsoftu přestaly fungovat. To mi úplně stačí.

co se týká IE7, žádný browser nezaručuje stejné vykreslování stránek, viz W3C standardy.

Takže, jinými slovy, pro vývojáře aplikací s webovým rozhraním neexistuje žádná ochrana jejich investic. To jsem chtěl říci, díky, že jste to uznal.

jaké KONKRÉTNÍ rozhraní nebude podporovat?

Nevím, za ty roky jich Microsoft vytvořil desítky. Předpokládáte, že tady všechna budou za 20 let?

až zkrachuje Sun, tak Java stále bude žít.

Jak to víte? Co když všichni za čas přejdou na .NET, Mono nebo na něco docela jiného? Kde máte tu záruku?

"Veškerý tento kód by se dal poměrně snadno převést do přeložitelné podoby. Velice jednoduše by se dalo ověřit, že přeložený program bude funkčně ekvivalentní."

Dal, ale přesto jak vidíte se to neděje, neboť usnadnění kompatibility a její zachování je pro někoho víc, než prázdný pojem. Výrobci kompilátorů chápou, že je to důležité.

"Mohl byste už konečně zanechat toho bullyingu?! Nestačilo Vám napsat jednou, že na takovýto způsob argumentace nejsem zvědavý?!"

Mě nebudete poroučet na co jste zvědavý, to si prosím odpusťte. Děkuji. Pokud Vám vadím, ignorujte mě.

"Například některé aplikace od Microsoftu přestaly fungovat. To mi úplně stačí."

Pokud existuje milión aplikací a třeba dvě přestanou fungovat, je to velmi kompatibilní věc.

"Takže, jinými slovy, pro vývojáře aplikací s webovým rozhraním neexistuje žádná ochrana jejich investic. To jsem chtěl říci, díky, že jste to uznal."

Pokud vývojáři aplikací očekávají víc, než je ve standardech je to naprosto v pořádku. Pak se nejedná o porušení kompatibility a o porušení ochrany investic nemůže být ani řeči.

"Nevím, za ty roky jich Microsoft vytvořil desítky. Předpokládáte, že tady všechna budou za 20 let?"

Nemáte argumenty? Nemůžete na nic konkrétního ukázat? Takže jen planě kladete písmena.

"Jak to víte? Co když všichni za čas přejdou na .NET, Mono nebo na něco docela jiného? Kde máte tu záruku?"

Pak stále budou existovat kompilátory stejně jako dodnes exitují třeba kompilátory COBOLu, nebo FORTRANu, nebo PL/I, nebo dalších jazyků, protože je potřeba ochránit investice projektů, kterých je obrovské množství. Stačí?

Jinak jediná Vaše 100% záruka je, že umřete. Cokoli jiného je jenom na 99,999% a mě 99,999% záruka ochrany investic přijde dostatečná.

> Dal, ale přesto jak vidíte se to neděje, neboť usnadnění kompatibility a její zachování je pro někoho víc, než prázdný pojem. Výrobci kompilátorů chápou, že je to důležité.

Výrobci kompilátorů Vás chápou. Já vlastně taky.

> Mě nebudete poroučet na co jste zvědavý, to si prosím odpusťte. Děkuji. Pokud Vám vadím, ignorujte mě.

OK, beru na vědomí, že se úmyslně chováte jako neotesaný hulvát a totéž od nynějška očekáváte od jiných.

> Pokud vývojáři aplikací očekávají víc, než je ve standardech je to naprosto v pořádku. Pak se nejedná o porušení kompatibility a o porušení ochrany investic nemůže být ani řeči.

Protože žádná ochrana neexistuje. Jak mazané.

> Nemáte argumenty? Nemůžete na nic konkrétního ukázat? Takže jen planě kladete písmena.

Samozřejmě. A nejenom já v tomhle threadu.

> Pak stále budou existovat kompilátory stejně jako dodnes exitují třeba kompilátory COBOLu, nebo FORTRANu, nebo PL/I, nebo dalších jazyků, protože je potřeba ochránit investice projektů, kterých je obrovské množství. Stačí?

Samozřejmě. A protože je Python open source (a interpreter je napsaný v C, které je věčné!), tak si můžete chránit svoje investice s interpreterem ve verzi 2.X, jak dlouho budete chtít. A s poněkud reálnějším využitím, než má kompilátor PL/I.

> Jinak jediná Vaše 100% záruka je, že umřete. Cokoli jiného je jenom na 99,999% a mě 99,999% záruka ochrany investic přijde dostatečná.

Kdo Vás naučil takhle hezky počítat? Váš přednášející ze statistiky?

"OK, beru na vědomí, že se úmyslně chováte jako neotesaný hulvát a totéž od nynějška očekáváte od jiných."

Já Vám jenom jemně naznačil, že nebudu skákat jak Vy pískáte. Pokud si za svým názorem stojím, tak ho hájím. Pokud v tom vidíte neotesané hulvátství prosím, vyvracet Vám to nebudu.

"Protože žádná ochrana neexistuje. Jak mazané."

Pokud neexistuje standard, neexistuje ochrana. To je normální.

"Samozřejmě. A nejenom já v tomhle threadu."

Uf, takže nic konkrétního nemáte. Ok. Na rozdíl od jiných v tomto threadu, kteří diskutují seriózně a konkrétně, když si o to říkáte.

"Samozřejmě. A protože je Python open source (a interpreter je napsaný v C, které je věčné!), tak si můžete chránit svoje investice s interpreterem ve verzi 2.X, jak dlouho budete chtít. A s poněkud reálnějším využitím, než má kompilátor PL/I."

Nemůžu, protože možná je interpretr v C, ale knihovny, které je potřeba také používat Vám tuto věčnost nezaručují. Stejně tak jako návaznosti na další věci. Kompilátor PL/I je možná málo používaný, ale stále existuje, protože je potřeba chránit investice. Python je sice open source, ale to je nepodstatné, podstatné je, že prostě existuje forma standardu ve formě PEP a ta by se měla dodržovat. Jinak Pyton není open source v sw smyslu, protože Python není program, ale jazyk. Open source může být konkrétní implementace jazyka. To je stejné jako byste řekl, že IP protokol je open source.

"Kdo Vás naučil takhle hezky počítat? Váš přednášející ze statistiky?"

Dojdou-li mi argumenty, pokusím se zesměšnit oponenta alespoň emotivně. Buď napište něco konkrétního, co se Vám nelíbí, nebo prostě jen blafujete.

> Já Vám jenom jemně naznačil, že nebudu skákat jak Vy pískáte. Pokud si za svým názorem stojím, tak ho hájím.

To je v pořádku. Mně se nelíbil a nelíbí ten způsob, jakým ho hájíte.

> Buď napište něco konkrétního, co se Vám nelíbí, nebo prostě jen blafujete.

> Nemůžu, protože možná je interpretr v C, ale knihovny, které je potřeba také používat Vám tuto věčnost nezaručují.

Knihovny jsou rovněž psané v C, resp. v C++, ne-li rovnou v Pythonu. Pořád tam nevidím slabé místo.

> Uf, takže nic konkrétního nemáte. Ok. Na rozdíl od jiných v tomto threadu, kteří diskutují seriózně a konkrétně, když si o to říkáte.

:-)

> Python je sice open source, ale to je nepodstatné, podstatné je, že prostě existuje forma standardu ve formě PEP a ta by se měla dodržovat.

PEP není standard. To je jenom návrh, jak v nějaké oblasti Python posunout kupředu. Jediné, co je podle mě směrodatné, je Language Reference a Library Reference. A platí pouze pro danou verzi překladače.

> Python není program, ale jazyk.

Napsal jsem "Python" a myslel jsem "CPython", který umožňuje spouštět programy psané v jazyce Python. To se stává.

> Buď napište něco konkrétního, co se Vám nelíbí, nebo prostě jen blafujete.

Konkrétně se mi nelíbí lehkovážné žonglování s čísly a procenty, byť možná v rámci nadsázky. Protože kdybyste připustil, že 99,999% možná není ve skutečnosti 99,999%, ale ze statistického hlediska výrazně méně, v tu ránu bychom se mohli dostat k tomu, že je třeba stanovit hladinu významnosti pro ověření Vaší hypotézy a vůbec bychom se museli z říše dojmů posunout k nějaké použitelné metodologii odhadu rizik. Což by bylo pro mě velice zajímavé, ale obávám se, že z tohoto threadu bude jenom to jalové kladení písmen.

znáte kompilátor jazyka C, který neumí přeložit K&R metody? já ne a to jich znám desítky od jednočipů po ...

Nevím, nezjišťoval jsem to. Tvrdím ale, že kdyby od června 2008 všechny najednou přestaly tyhle metody překládat, naprosto nic hrozného by se nestalo.

až budete mít sw s pár milióny řádky, který léta ladíte a pak ho pomocí nástroje budete měsíc přepisovat a samozřejmě tam zanesete takto nové chyby, takže bude nestabilní jak na začátku, znovu projít náročnými testy atd..

A kolik programů s pár milióny řádky v Pythonu máte Vy? Pro zajímavost, v Zope 2.10 je něco přes půl miliónu řádků v Pythonu.

ten přechod může trvat řadu let, ale důležité je, že se připravuje, a že se nehodlá nikdo zpětnou kompatiblitou vážněji zabývat.

To snad nikdo netvrdil, že se problémem nebude vážně zabývat.

z toho jasné vyplývá, že investice do kódu v pythonu nehodlají vývojáři ochránit a je to signál pro ty, kdo potřebují vyvíjet větší aplikace, které se budou řadu let udržovat - a ten signál je, že python není vhodný.

Kdo ochránil investice vývojářů, kterým nechodí aplikace pod Windows Vista? Kdo ochrání Vaše investice, až vyjdou nové Windows a Microsoft se rozhodne nějaké rozhraní přestat podporovat? Kdo ochránil investice vývojářů webu, pokud zjistili, že IE7 nevykresluje dobře stránky? Kdo ochrání Vaše investice do kódu v Javě, pokud zkrachuje Sun? O jakých zárukách se bavíme? Jaké REÁLNÉ problémy se řeší?

chytrý poslouchá teď, hloupý pak řeší až nastanou problémy.

Takovýto typ "argumentace" se mi nelíbí.

Nesuhlasim. Kazdy jazyk z casu na cas porusi spatnu kompatibilitu. Java pri verzii 1.2 a .NET pri 2.0.

Alebo, vezmite si napriklad C++ - nedbajuc na spatnu kompatibiltu sa menil nielen standard ale aj kompilatory. Dobre sa pamatam na bolestny prechod z Visual C++ 6.0 na Visual C++ 2005. Tu je obzvlast pikantne, ze mnohe POSIX funkcie boli oznacene ako osolete. Podobne nestandarny bol prechod z g++ 2.9.5 -> 3.x alebo g++ 3.x -> 4.x. C++ skratka bolo a bude nocnou morou spravcov projektov.

Osobne si myslim ze Python je seriozna platforma a preto aj Python 3000 je dnes len utopia. Pre odoberanie funkciii sa schvalila velmi konzervativna politika a zasadne zmeny v jazyku tiez nie su na programe dna. Napri. nikto, kto ma zdravy rozum, si dnes nevie predstavit zmenu operatora / z celociselneho delenia na realne. Skratka, python dozrel.

Porušit zpětnou kompatibilitu ve verzi 1.2 se dá celkem pochopit a tolerovat. Mnoho jazyků jí poruší při přechodu z verze 1 do verze 2, to je takový folklór. Ale pak by to mělo končit.

C++ nic neporušilo. standard C++ je stále jeden, platný a porušovat se nikdy nebude ani se to neplánuje. předtím neexistoval standard C++, ani psaný, ani nepsaný, tudíž nebylo co porušovat. takže noční můry se nekonají.

python není seriózní platforma, protože je příliš "volná". seriózní platforma to bude, až každému vývojáři bude jasné, že byť jen uvažovat o porušení kompatiblity je hloupost, a nebo aspoň velmi vážná věc, která musí mít sakra dobré důvody. a až když někdo navrhne nekompatibilitu, druzí ho samozřejmě a bez přemýlšení seřvou. a taky až bude existovat přenositelný binární formát tohoto jazyka, který umožní přenositelnost aplikací i bez zdrojových kódů. java tohle umožňuje i napříč verzemi.

Ze znamkou serioznosti platformy ma byt skutecnost, ze nekdo nekoho _bez premysleni_ serve, si muze myslet jen znamy urvanec Miloslav Ponkrac, ktery tu rve bez premysleni.

Dekuji za vas nazor, ze pro vas Python neni seriozni platformou, pro me neni seriozni vas nazor bez premysleni. Osobne jsem rad, ze vyvojari Pythonu premysli, to povazuji za mnohem lepsi ochranu investic.

Pro ostatni. Zadny Python 3000 neexistuje ani se nevyviji. Tvrzeni ze pristi verze Pythonu bude nekompatibilni je lez. Python je jazyk zivy a stale se vyviji, takze srovnavat ho s mrtvou Adou nebo C je nesmyslne. K drobnym upravam kodu je nutno pristupovat i dnes. Napriklad existuje nekolikalety plan postupneho prejiti z textovych vyjimek na objektove a pritom uz pred radou let platilo pravidlo, ze ty textove by se nemely pozivat. V praxi to nedela problemy a jak bylo uvedeno, kdyby bylo nejhur, porad je tu moznost pouzivat interpretr s podporou starsi verze jazyka.

Petr Mach už nemá argumenty a tak se tu zoufale schyluje k osobním útokům.

Python 3000 se připravuje a plánuje a deklaruje se, že bude nekompatibilní. Pokud lžu, pak lžou i ofociální stránky pythonu, stejně jako třeba anglická wikipedie. Možnost staršího interpretru odpadne časem, protože se nebude až moc vyvíjet.

standard C++ je stále jeden, platný a porušovat se nikdy nebude ani se to neplánuje.

Sorry, ale nemate o tom ani paru.

ale rozumím, programuji v C++ od roku 1991. vím, že se to měnilo jako ponožky, ale standard vznikl v roce 1999 a ani příští standard, který se připravuje nehodlá nijak měnit zpětnou kompatiblitu

A kdyby někdo Python 3000 přejmenoval třeba na ".ORG platform framework", tak budete s kompatibilitou současného Pythonu spokojený?

Spíš mi to přijde jako takové manažerské argumenty, že v tom neprogramujete, ale opíráte se o nějaká prohlášení někoho. Kdyby ta prohlášení byla formulována jinak, tak se nad tím ani nezastavíte.

Zkuste si udělat nekompatibilní Javu, nebo Adu a nazvěte to Javou, nebo Adou a můžete se připravit na soudní proces. Pak bych vám doporučil mimosoudní vyrovnání, jinak přijdete i o kaťata. Právě z těchto důvodů jsou tyhle jazyky používány tam, kde o něco opravdu jde.

Pokud se Python bude stále vyvíjet kompatibilně a nikdo si udělá něco pod jiným jménem už to není Python a je to jedno.

V Pythonu jsem toho napsal moc a moc a právě proto mě to štve.

Vývojáři Pythonu udržují seznam požadavků na změny, které by bylo vhodné provést, ale nemohou kvůli zpětné kompatibilitě. Nikdo neprohlásil, že příští verze Pythonu bude nekompatibilní se stávajícími. Šíříte poplašnou zprávu.

I kdyby Jednou za 10, 50 nebo 993 let Python 3000 vzniknul, pořád bude možno stávající aplikace provozovat na Pythonu 2.x, protože mu nečiní problémy paralelního chodu více verzí současně, tudíž není potřeba nic předělávat, a o žádné ohrožení investic se nejedná, takže zklidněte hormony a nedělejte z komára velblouda.

Já doufám, že jednou Python 3000 vznikne a vyřeší se tak multiprocesorový běh interpretu a vylepší podpora multithreadů, což bez ztráty zpětné kompatibility (knihoven, nikoli kódu) není možné.

Ostatně, taková Windows Vista nebo IE7 jsou nekompatibilní až hrůza a co se děje? Přestanou podnikoví ekonomové Windows používat?

v tom případě šíří poplašnou zpávu i oficiální web pythonu, stejně jako třeba wikipedie. prosím vynadejte jim tam, jmenovitě GvR.

ne, nebude možné provozovat apliakce na python 2.x, protože vývoj 2.x bude upadat, až se stane nepoužitelným. mohu se zpetat, udržuje někdo stále aplikace pro Linux 1.0, nebo pro Windows 2.0? Udržuje se maximálně něco pro určitý počet let starého a pak šlus. opravdu si myslíte, že autoři každé z tisíců knihoven budou udržovat verzi pro všechny potenciální nekompatibilní verze pythonu?

jenže změny, které se navrhují jaksi neření multicosi, ale jen to, že GvR prohlašuje, že tato konstrukce musí zmizet, protože není dostatečně "pythonoská", nebo že se mu špatně implmentuje. pokud by mělo porušení zpětné kompatibility výrazný benefit jinde, pak se to možná dá omluvit, ale ono to v pythonu 3000 tak není!!!

Windows Vista je kompatibilní se slušnými, tj. standardně napsanými aplikacemi dokonce Windows 1.0 (tuším asi dvacet staré), nebo dokonce DOS. co je tam tak nekompatibilního?

Až Windows budou opravdu hrubě nekompatibilní, tak podnikoví ekonomové přestanou Windows využívat, na to se můžete spolehnout. A Microsoft to ví, na rozdíl od GvR. Proto každou nekompatibilitu, kterou je nucen zavést si tvrdě rozmyslí a pokud je, tak má pro ní sakra důvod. A pokud by zavedl nekompatibilitu, tak můžete měsíc slavit, protože Windows je poražen a je volná cesta Linuxu. Něco nejasného?

Odporujete si sám sobě.

Máte vaši aplikaci co funguje s pythonem 2, máte pro to knihovny co fungují. Ty knihovny jsou založené na neměnném rozhraní operačních systémů a neměnném C nebo na tom pythonu co máte, takže vám teoreticky budou fungovat navždy (nebo jsou podle vašeho vlastního názoru jejich programátoři prasata a pak nevím proč je používáte, to je čistě váš problém v takovém případě). Že vám nikdo nebude vydávat nové verze, to jednou taky přijde. Nicméně to co máte budete mít jednou provždy. Programátoři v PL/I asi taky nemají obrovský výběr všeho možného pro svůj programovací jazyk a těžko se mohou čemu divit, když používají exotický kus šrotu.

ale nebude. chcete říci, že stále budou pro python 2 rozhraní pro nové a nové verze databází, xml a dalšího? že i po deseti letech co skončí aktivní vývoj pythonu 2 bude k dispozici pro python 2 wrapper na aktuální verzi mysql řekněme verze 50, nebo na sqlite verze 40? nebo k pythonu 2 budete muset mít i deset let starou verzi databází? a to nemluvím o dalším. vývoj stejně učiní python 2 nepoužitelným pokud se jeho vývoj zastaví.

To je jak u blbych. Nikdo krome vas netvrdi, ze pristi verze pythonu bude nekompatibilni, proto poplasnou zpravu sirite vy.

Ad linux 1 a windows 2. a) Jestlize udrzovat zpetnou kompatibilitu za nutne nepovazuji vyvjari linuxu a Windows, roc by to meli delat vyvijari pythonu? b) Kde jste prisel k tomu, ze to vyvijari pythonu delat nebudou?

Ad python 3000. Tento python neexistuje ani se nevyviji, vas prispevek je proto nesmyslny a na hlavu postaveny.

Windows Vista neni kompatibilni ani s aplikacemi od Microsoftu pro Windows XP, a to je uz co rict.

Na rozdil od Pythonu jsou aplikace Microsoftu tezce nekompatibilni, viz windows, IE, .NET, VB, Access a rada dalsich a jak se microsoftu dari. Uzivatele zjevne pred kompatibilitou preferuji rychly vyvoj. Takze si o GvR neotirejte usta, ktery vyvoj zene kupredu, ale kompatibilitu drzi na uzde.

Je strašně hezké, že dementujete slova samotného tvůrce Pythonu Guida van Rossuma, který naopak tvrdí, že python 3000 bude nekompatibilní. Vidím, že jste jeho mluvší, a že Vás poslouchá jako pejsek na slovo. Co řekne Mach, to platí, i když vývojáři pythonu tvrdí opak.

Vývojáři windows i linuxu mají stálé API, kde jste přišel na tu zoufalou nekompatibilitu. Drobnosti se mění, ale jinak základ zůstává.

Zbytek už nehodlám komentovat, zkomantoval jsem jinde a vzledem k tomu, že pan Mach evidentně tvrdí naprosto opačné věci co tvůrce pythonu je to mrháním energií.

v tom případě šíří poplašnou zpávu i oficiální web pythonu, stejně jako třeba wikipedie. prosím vynadejte jim tam, jmenovitě GvR.

ne, nebude možné provozovat apliakce na python 2.x, protože vývoj 2.x bude upadat, až se stane nepoužitelným. mohu se zpetat, udržuje někdo stále aplikace pro Linux 1.0, nebo pro Windows 2.0? Udržuje se maximálně něco pro určitý počet let starého a pak šlus. opravdu si myslíte, že autoři každé z tisíců knihoven budou udržovat verzi pro všechny potenciální nekompatibilní verze pythonu?

jenže změny, které se navrhují jaksi neření multicosi, ale jen to, že GvR prohlašuje, že tato konstrukce musí zmizet, protože není dostatečně "pythonoská", nebo že se mu špatně implmentuje. pokud by mělo porušení zpětné kompatibility výrazný benefit jinde, pak se to možná dá omluvit, ale ono to v pythonu 3000 tak není!!!

Windows Vista je kompatibilní se slušnými, tj. standardně napsanými aplikacemi dokonce Windows 1.0 (tuším asi dvacet staré), nebo dokonce DOS. co je tam tak nekompatibilního?

Až Windows budou opravdu hrubě nekompatibilní, tak podnikoví ekonomové přestanou Windows využívat, na to se můžete spolehnout. A Microsoft to ví, na rozdíl od GvR. Proto každou nekompatibilitu, kterou je nucen zavést si tvrdě rozmyslí a pokud je, tak má pro ní sakra důvod. A pokud by zavedl větší nekompatibilitu, tak můžete měsíc slavit, protože Windows je poražen a je volná cesta Linuxu. Něco nejasného?

Já jsem aplikaci pro Windows 1.0 zkoušel spustit na Windows 3.1 a seřvalo mě to, že aplikace je pro jinou verzi Windows. Ad ta kompatibilita windowsXdos --- ono se to taky bohužel na několika místech dají celé XP přes 16bitové programy shodit. Kdyby to aspoň měli správně navrženo --- tak, že žádná část toho emulátoru DOSu nebude běžet s vyššími privilegiemi.

Jinak ad kompatibilita Windows --- znám člověka, co přišel o data na disku, když disk z Windows 2000 strčili do XP nebo obráceně (ne o všecka data, ale nějaké soubory to zničilo).

Windows 3.1 už neuvažuju, berme win 2k, xp - nic jiného dnes se nepodporuje.

Co se týká disků, vůbec se nedivím, protože prostě windows nepočítají s tím, že se disky budou strkat do jiné verze. Tudíž jde o nepodporovanou vlastnost, ntfs je pokaždé jiný.