Jak jsem si oblíbil Python

Doporučuji kouknout na Ruby (http://ruby-lang.org/en/), což je takový Python kombinovaný se Smalltalkem.

Dělal jsem dlouho v Pythonu, pak zkusmo přešel na Ruby a zůstal u něj.

Nevím, v jakém stavu je Python dnes, ale umí třeba za běhu programu zcela transparentně přidat metodu libovolné "hard-coded" třídě (např. třídě "String" nebo "Integer") - bez jakéhokoliv složitého hackování?

K té "nativitě" wx* - na OSX to většinou vypadá dost nepřátelsky, chystám o tom povídání...

Já jsem Python dlouho zkoumal, stejně tak jako Ruby a došel jsem k závěru, že Ruby nikdy (nepodpora Unicode v jazyce a další věci, které nedokážu už překousnout, a které od moderního jazyka automaticky očekávám). Kromě toho Ruby si odneslo od Smalltalku spíš to horší, jako je nesmyslná emulace operačního systému, jako třeba v případě threadů, kde si Ruby nesmyslně vymýšlí své vlastní, ačkoli hostitelský operační systém to zcela jistě zvládne lépe. A v neposlední řadě je tu ještě subjektivní důvod a to ten, že nesnáším Perlovskou syntaxi a Perloviny v jakémkoli jazyce, což v Ruby trochu vidět je. Takže mám třikrát posychrované, že se Ruby věnovat nechci a jeho návrh se mi nelíbí.

V Pythonu jsem pár věcí napsal a píše se v něm opravdu rychle. Ale pak Vám začne nastavovat i tu druhou tvář. Dokumentace je mizerná. Když jsem s Pythonem začínal, připadala mi dokumentace velmi kvalitní, ale po čase jsem zjistil, že v ní prostě podstatné informace hledáte jen stěží. Python má knihovny ve stylu "každý pes jiná ves", takže nějakou konzistenci jsem už dávno přestal hledat. Spoustu efektivních věcí v Pythonu, jako jsou různá funkcionální rozšíření, lambda funkce, map, reduce a další hrozí autor Pythonu, že v příští verzi Pythonu nebudou. A pro někoho výhoda, pro někoho nevýhoda, autor Pythonu se snaží udělat jazyk tak jednoduchý pro začátečníky jak jen může, což je někdy i na škodu. Především nenávidí syntaxi Céčka, a mnoho Céčkovských elegantních zápisů mi v Pythonu chybí (například teze, že přiřazení je výrazem), takže leckdy jednodušší věci napíšu rychleji v C, než v Pythonu. Což je škoda, protože Python by měl rozhodně na víc.

Python je rozhodně vynikající programovací jazyk, ale upřímně řečeno jak jsem jím byl nadšený, dnes jsem umírněnější a říkám, že dnas se objeví něco lepšího, co negativní rysy Pythonu opraví a bude to velmi elegantní jazyk. Našel jsem jazyk Boa, který toto přesně dělá - tedy obohacuje a rozšiřuje Python směrem, který se mi velmi zamlouvá, ale je k dispozici pouze pro .NET prostředí, což se mi zase nelíbí.

Napsal bych ještě víc, zejména ohledně praktických zkušeností s knihovnami, které tu autor popisuje, ale vzhledem k tomu, že tu nefunguje automatické posílání reakcí na mail se s tím nebudu obtěžovat.

[3]: Nebudu kontrovat subjektivním názorům svými subjektivními názory, jen opravím, že Ruby podporuje Unicode zcela transparentně a bez problémů (a nevzpomínám si, že by ho někdy nepodporovalo, vždyť ho vymyslel Japonec)! Celé stránky fuxoft.cz jsou generovány dynamicky pomocí jednoduchého Ruby scriptu (s diakritikou, v Unicode).

jak jsou na tom ruby a python s knihovnami pro snmp?

5: http://snmplib.rubyforge.org/

to František Fuka: Musím opravit, Ruby NEMÁ podporu Unicode na úrovni jazyka, ale pouze na úrovni knihoven. Což přináší jisté nepohodlí při programování. Nehledě na to, že doby, kdy bajtový proud a řetězec jedno jsou už jsou doufám dávno pryč, i když pravda Ruby si to stále ještě nemyslí.

Snad bych měl napsat, že Unicode pouze na úrovni knihoven nepovažuji za dostatečné řešení.

Je to právě o to nepochopitelnější, že Ruby vymyslel Japonec. Taky bych očekával, že automaticky vyřeší i Unicode, ale holt se tak u Ruby nestalo.

Na druhé straně je nutné říci, že Ruby má i spoustu pěkných vlastností, nicméně si nemyslím, že Ruby je správná cesta. A asi si to nemyslím jenom já, protože když se podívám na statistiku počtu projektů v Ruby na freashmeat.net, dostanu jen mizivé číslo. Kromě Ruby on Rails je využití Ruby dost mizivé.

Mě osobně by vyhovoval spíš čistokrevný Smalltalk, kdyby ale existoval ve verzi, která není vázána na to jeho prostředí. Nevím, proč se Smalltalk musí tvářit jako operační systém a všechno si dělat po svém včetně okýnek.

7: Nevim, jak myslite to "na urovni knihoven" a "doby, kdy bajtovy proud a retezec jedno jsou...". Pokud vytvorim v ruby standardnim zpusobem retezec "dědeček" (pomocí příkazu text="dědeček", bez nějaké knihovny), tak ma tento string zcela spravne 7 znaku a 9 bajtu - je na me, jestli s nim chci pracovat po znacich (pomoci ".each") nebo po bajtech (pomoci ".each_byte"). Manual rika: "Ruby programs are written in 7-bit ASCII, Kanji or UTF-8" - opet zadna zminka o nejake knihovne. A to vsechno jsou "Kernel-level built-in functions". Takze co myslite tim "Pomoci knihoven"?

Já jsem si s Pythonem hrál jen chvilku a pak jsem se zděšením utekl zpátky k Perlu. Jediné, co se mi na Pythonu líbilo, byly bloky odsazováním. Příšerná mi přišla chybová hlášení, z tracebacku jsem většinou nebyl schopen poznat ani ň. Taky tohle je fakt dobrej fór:

Traceback (most recent call last):
File "./imaging", line 20, in ?
sum += image.getpixel(i, j)
TypeError: getpixel() takes exactly 2 arguments (3 given)

A regulární výrazy… Hnus. Ne že bych je psal dnes a denně, ale šiknou se často a tohle:

import re
p = re.compile('[a-z]+', re.IGNORECASE)
if (p.match("moo"))

…je opravdu zběsilost. Dokumentace byla tehdy (tak dva roky zpátky) velice bídná, nebyl jsem schopen se doklikat ničeho jiného než tisíce tutoriálů s kalkulačkou (to už je asi fakt postižení).

Interpolace proměnných v řetězcích mi taky připadla drobet praštěná, no zkrátka jsme si do oka nepadli :)

Na Perlu mě hodně bere CPAN a vadí mi v podstatě jen malá… uf, ortogonalita jazyka. Jenže z té zase plyne tisíc výhod, tak už u něj asi zůstanu.

Mimochodem se dost těším na to, co s Perlem, Pythonem, Ruby a spol. udělá příchod Parrota (http://www.parrotcode.org/).

7: Smalltalku, ktere "nejsou vazany na jeho prostredi" je nekolik, napr. SmalltalkX, MTSmalltalk nebo GNU Smalltalk (pokud tim myslite napr. "Nema to vlastni Smalltalkovou spravu oken"). Ve Smalltalku jsem delal tri roky pred tim, nez jsem presel na Ruby, napsal jsem v nem multiuser online hru pro Eurotel a i kdyz se mi velmi libila jeho "cistota", bohuzel jsem narazil na jeho pomalost a predevsim malou uzivatelskou zakladnu (ve srovnani s Pythonem nebo Ruby) a tudiz nemoznost jine podpory, nez placene. A pokud budeme kvalitu merit poctem "projektu na freshmeatu", tak uplne nejlepsi jazyk na svete je bezpochyby C... :)

8>

$ perl -Mutf8 -e "print uc('ještěrka');"
JEŠTĚRKA

$ perl -Mutf8 -e "'Š' =~ /\w/ && print 'Ano, Š je písmeno.'"
Ano, Š je písmeno.

Není v tomhle ten problém? Ukaž v Ruby.

to František Fuka: To se nám to hezky zamotává :-) Vnitřní ukládání řetězců v utf-8. Ok, jako z nouze ctnost, proč ne? utf-8 je dobrý formát na import/export, ale zpracování řetězců vnitřně je mnohem lépe provádět v nějakém kódování s pevně danou šířkou znaku.

Celé to utf-8 vzniká z toho, že řetězec je pro Ruby stále jen proud bajtů, jak ostatně píšou i v manuálu. Stringy slouží v Ruby k ukládání sekevencí 8-bitových bajtů. Je jasné, že taková sekvence se dá znásilnit.

to zoul: Tedy ne že bych chtěl Python obhajovat, ale právě věci, které píšete bych hodnotil úplně opačně, než Vy. Hlášení chyb mi přišlo velmi pěkné a důsledné využívání výjimek hodnotím pouze kladně. Ne, že by nebylo co na výjimkách v Pythonu zlepšovat, ale v zásadě se mi líbí.

Nehledě na ty možnosti, možnost odchytit a vyrovnat se třeba se syntaktickou chybou ve zdrojáku Pythonu volaném z jiného modulu v Pythonu je nádherná. Natolik neznám Perl, abych mohl říci, zda lze něco v Perlu podobného vůbec mít.

S regulárními výrazy je to otázka. Kam až mám být jazyk schopen nahrazovat knihovny. I regulární výrazy v Pythonu lze přepsat na jeden operátor, to není problém. Mě třeba v Perlu dost vadí styl typu "udělej si sám". Objekty, výjimky a mnohé další věci v Perlu mě budí dojem silného nalepováku.

S dokumentací k Pythonu souhlasím. Je příšerná a dost často naprosto k ničemu.

Jinak co udělá Parrot je jasné. Napíšou se verzi Perlu, Pythonu a Ruby, které pojedou na něm, co jiného čekáte? Spíše jsem zvědav co udělá s Ruby yarv.

10: Velice děkuji za informace o Smalltalku.

Ad počet projektů. Počet projektů není zcela relevantní číslo, ale u Ruby se opravdu pohybuje velmi těsně u nuly. A to už něco znemaná.

11: Myslím, že na to jdete špatně. V regulárních výrazech prostě Perl má navrch. Nic více a nic méně. Řekněme jakožto problémově orientovaný jazyk na textové manipulace bych Perl bral. Ale co jiné věci?

Mimochodem, to co píšete jakožto ukázku v Perlu je třeba v Pythonu otázka napsání jedné malé knihovny. Pak bude syntaxe práce s regulárními výrazy prakticky srovnatelně stejně jednoduchá jako v Perlu. Předpokládám, že v Ruby je to to samé, ale větších zkušeností nemám, takže zůstávám u předpokladu.

15> Vůbec mi nejde o syntaxi, ale o to, jestli Ruby vážně počítá s UTF-8. Způsob uložení řetězců mě třeba ani zdaleka nezajímá jako to, jestli jazyk v UTF řetězci správně interpretuje \w.

„Jinak co udělá Parrot je jasné. Napíšou se verzi Perlu, Pythonu a Ruby, které pojedou na něm, co jiného čekáte?“

Zajímalo by mě, jestli se třeba dočkáme „nového CPAN“ (Comprehensive Parrot Archive Network) a jedné jediné virtuální mašiny, na které pojedou Python, Perl i Ruby. Zajímalo by mě, jestli půjde kusy kódu z jednotlivých jazyků bez problémů kombinovat.

Pokud zůstane jen u shodného běhového prostředí a jinak si všichni budou dál hrát na svém písečku, tak by mi to přišlo líto.

(Na druhou stranu, o čem bychom pak diskutovali? Ještě že tu vždycky zbývá diskuse vim vs Emacs. I když ta už je taky vlastně vyřešená, kdo by se patlal s Emacsem :)

V regulárních výrazech je v Ruby správně rozlišeno, že "š" je písmeno. Defaultní funkce .upcase má své dokumentaci napsáno "only characters a to z are affected", tj. nefunguje tak, jak si představujete.

18> Jenže alespoň podle mých pokusů nikoliv uvnitř Unicode řetězce:

print "Yep" if /\w/.match("Moo")
Yep=> nil

print "Yep" if /\w/.match("š")
=> nil

Pokud to nejde nějakým přepínačem zprovoznit, je podle mého praktická podpora Unicode v Ruby dost vratká.

17: Co se týká CPANu a hraní na svém písečku, budou platit obě verze, tedy správná odpověď bude ano i ne. Určitě bude možnost, jak využívat knihovny druhého jazyka a zároveň si každý jazyk podrží své vlastní.

Ale pokud bych si dovolil zavěštit, tak Perl určitě bude mít dobrou budoucnost (přestože Perl nemám moc rád), protože jeho autor se tomtuto tématu věnuje pocitvě, efektivně a na plný úvazek. Kromě toho komunita Perlu je aktivní a k Perlu značně přispívá.

O budoucnost Pythonu se bojím. Python drží jeho autor pevně v rukou, ale má na něj čím dál méně času. Nejdříve jej před léty dělal na plný úvazek, pak jej především využíval a teď je zaměstnán v google, kde sice v Pythonu programuje, ale pravděpodobně na vývoj jazyka nebude mít čas. A komunita Pythonu jazyk moc nevyvíjí, mnoho Pythonistů jsou Céčkaři, kteří obalují knihovny do něj.

Vývoj Ruby se mi zdá příznivější, ale zase na druhé straně se mi nelíbí některé věci v jazyce samotném. Otázkou je co komunita. Rubysti jsou trochu fanatičtější, než jinde. Ale Ruby se vyvíjí, jde určitým směrem, tak by nemuselo dopadnou tak špatně.

19: Bud si spravne nastavte environment, aby Ruby vedel, ze ma defaultne bezet v Unicode (korektni reseni), nebo na konec vyrazu pridejte u (mene korektni reseni) a tim mu natvrdo prikazte, ze jde o unicode retezec: napr. print "Yep" if /\w/u.match("š")

21> Pravda, funguje, v tom případě nemám námitek.

>...utf-8 je dobrý formát na import/export, ale zpracování řetězců vnitřně je mnohem lépe provádět v nějakém kódování s pevně danou šířkou znaku....

Java/C# používají kódování utf-16. Takže je to jedno.

23: Nikde jsem netvrdil, že Java/C# je dobré řešení. Nicméně u Javy to vzniklo snahou o dobrou podporu Unicode, prostě v dobách návrhu Javy stačilo 16 bitů na znak. Dnes už je to 21 bitů, tudíž holt Java přešla na utf-16. Ale pro většinu aplikací těch 16 bitů stačí.

Ale Ruby se rozhodl pro špatný model v okamžiku, kdy měl v době návrhu informaci jak to je. Tudíž u Javy je to prostě proto, že neměli v době návrhu křišťálovou kouli, což s e dá pochopit. Ale u Ruby je to čisté diletantství.

Co nechápu, je utf-16 u C#, ale tam to přisuzuji tomu, že navazovali na Win API, které je také utf-16.

Pokud je Python oblibeny, doporucuji kouknout na Django - www.djangoproject.com Potom, co jsem zkoumal nekolik ruznych web frameworku (at uz od Pythonu - cherrypy, subway, nevow, atd., nebo Rails), tak jsem si rekl, konecne jeden s filozofii, ktera se mi zamlouva...

13> „Hlášení chyb mi přišlo velmi pěkné“

Teď jsem zrovna na jeden klasický příklad natrefil. Takhle vypadá výstup pythonovského programu, který jsem přerušil normálním ^C:

Traceback (most recent call last):
File "/usr/local/bin/a­tox", line 2, in ?
import atox.cli
File "/usr/lib/pyt­hon2.4/site-packages/atox/__i­nit__.py", line 4, in ?
from atox.OptionManager import OptionManager
File "/usr/lib/pyt­hon2.4/site-packages/atox/Op­tionManager.py", line 3, in ?
from optparse import OptionParser
File "/usr/lib/pyt­hon2.4/optpar­se.py", line 72, in ?
from gettext import gettext as _
File "/usr/lib/pyt­hon2.4/gettex­t.py", line 49, in ?
import locale, copy, os, re, struct, sys
File "/usr/lib/pyt­hon2.4/copy.py", line 65, in ?
import inspect
File "/usr/lib/pyt­hon2.4/inspec­t.py", line 31, in ?
import sys, os, types, string, re, dis, imp, tokenize, linecache
File "/usr/lib/pyt­hon2.4/tokeni­ze.py", line 100, in ?
tokenprog, pseudoprog, single3prog, double3prog = map(
File "/usr/lib/pyt­hon2.4/sre.py", line 180, in compile
return _compile(pattern, flags)
File "/usr/lib/pyt­hon2.4/sre.py", line 225, in _compile
p = sre_compile.com­pile(pattern, flags)
File "/usr/lib/pyt­hon2.4/sre_com­pile.py", line 496, in compile
p = sre_parse.parse(p, flags)
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 665, in parse
p = _parse_sub(source, pattern, 0)
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 308, in _parse_sub
itemsappend(_par­se(source, state))
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 625, in _parse
p = _parse_sub(source, state)
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 308, in _parse_sub
itemsappend(_par­se(source, state))
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 625, in _parse
p = _parse_sub(source, state)
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 308, in _parse_sub
itemsappend(_par­se(source, state))
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 625, in _parse
p = _parse_sub(source, state)
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 308, in _parse_sub
itemsappend(_par­se(source, state))
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 376, in _parse
subpattern = SubPattern(state)
File "/usr/lib/pyt­hon2.4/sre_par­se.py", line 90, in __init__
def __init__(self, pattern, data=None):
KeyboardInterrupt

…to mi přijde úplně padlé na hlavu. Jsou to drobnosti, ale například perl (ehm :) v tomhle případě utrousí „^C“, což je podle mě neskonale přiléhavější.

26: A Vy nevidíte ty možnosti toho hlášení chyb? Až budete ladit chybu, která Vám celé hodiny zoufale uniká, tak výpis zásobníkových volání, které tu předvádíte budete považovat za obrovský dar z nebes.

Vždyť tam máte všechny informace, které byste kdy potřeboval vědět. Víte, kde byl program přesně přerušen, v jakém souboru a na jaké řádce. Víte jaké všechny podprogramy byly volány a spoustu dalších věcí. Přesně to co předvedl Python je nejlepší příklad toho správného výpisu chyb jak má vypadat. Perl by se měl učit. Pokud bych na tom chtěl něco měnit, tak jedině tím směrem, že by Python vypisoval ještě více informací.

Programuji už dvacet let a všude kde to šlo jsem si upravil chybová hlášení tak, že se maximálně podobají tomu pythonímu. Takže třeba Java to vypisuje úplně stejně jako Python, a třeba PHP po mém zásahu a ve všech mých projektech také. Dokonce i v C/C++ mám stejná chybová hlášení.

Vám totiž uniká základní účel chybového hlášení, a to je ten, podat maximum informací, aby bylo možné chybu dohledat a nestrávit zbytečný čas luštěním strohých hlášení ála Perl, které jsou k ničemu a na dvě věci. Až budete mít na krku termín, že musíte projekt odevzdat ráno, jsou čtyři hodiny v noci a lovíte poslední chybu, která vám záhadně uniká a do toho máte k dispozici idiotský jazyk, který vypisuje strohé zprávy jako Perl a nic podorobnějšího Vám o chybě nepoví, tak byste vraždil. Takže ještě jednou, pythoní výpis chyb je ten správný výpis chyb jak má vypadat.

Navíc v Pythonu máte možnost klidně převést jeho chybový výpis na ten z Perlu, pokud po tom bažíte. Stačí odchytit výjimku KeyboardInterrupt a převést jí na výpis řetězce ^C. A hle vypisuje to hlášení ve stylu Perl. Říká se tomu flexibilita jazyka. Naopak to ovšem nejde, Perl pravděpodobně k ničemu lepšímu nedonutíte.

Bohužel Perl není jazyk na větší projekty, maximálně na zbastlení pár jednoduchých věcí. Vůbec si neumím představit psát v Perlu něco většího. To prostě nejde, náklady na údržbu takového většího programu v Perlu by převýšili pravděpodobně jeho užitečnost. Dokazuje to mimo jiné i stylem chybových hlášení.

Naproti tomu Python je jazyk, ve kterém můžete napsat milióny řádek a lze to rozumně udržovat. Je to podstatně profesionálnější přístup a chybová hlášení rovněž.

Uf, já vás s tím Perlem dráždím, že? Prostě jsem ilustroval, co se mi na Pythonu nelíbí. Perl jde k podrobnějšímu chybovému výpisu ve smysluplných případech samozřejmě donutit velice snadno, ale o to už vám asi nešlo.

No at si každý používá jazyk jaký mu vyhovuje nejvíce, že ;)

[26] jo, takhle má vypadat chybové hlášení, neco podobného (ovšem přehlednějšího) jsem si musel do PHP dodělat.

[12]
> utf-8 je dobrý formát na import/export, ale zpracování řetězců vnitřně je mnohem lépe provádět v nějakém kódování s pevně danou šířkou znaku.

No, v nějakém kódování... ono přichází v úvahu jen UCS-4. Jenže 4x větší paměťová náročnost není banalita, proto se nativně tak často používá UTF. Nakonec, ono UTF je výborné, pokud používáme operace zřetězení nebo analýzu řetězců znak po znaku (třeba regexp). Pak je stejně rychlé a šetří paměť. Problémový je přístup k jednotlivým znakům nebo zjišťování délky (což koneckoců platí i pro céčkové řetězce).

zoul: Tak to mně teda nepřijde ^C jako moc užitečná informace a ten traceback s typem výjimky je srozumitelný a konzistentní. Pokud se mně jakožto programátorovi nelíbí chybová hláška (pro uživatele je to asi děsivá záležitost), pak je správné řešení odchytnout KeyboardError a nepsat nic nebo napsat třeba v nastaveném jazyce "Běh programu byl přerušen uživatelem, nashle příště". ^C není k ničemu a pokud budu chtít, tak si ho holt vypíšu sám, jsou to přesně tři řádky navíc.

Pro mě je ^C ideální, protože stručně a jasně říká, k čemu došlo – nevybavuju si jediný případ, kdy bych po ^C potřeboval výpis zásobníku. Kdybych vážně chtěl, dopíšu si zpracování signálu („jsou to přesně tři řádky navíc“, v Perlu konkrétně jedna řádka kódu a jedna direktiva).

Výchozí chování Pythonu se mně osobně nelíbí, protože traceback mě jako uživatele nezajímá vůbec (a ještě jsem nenatrefil na Pythonovský program, který by výjimky ohlašoval slušně) a jako programátora většinou taky ne – zvlášť ve velkých aplikacích je pro mě traceback od třetí funkce výš úplně zbytečný. Viz například chybová hlášení Javových webových aplikacích, kde tak první tři řádky patří mému kódu a dalších klidně dvacet třicet probublává různými frameworky.

Ruku na srdce, fakt byste ten traceback četli celý? Mě z něj zajímá prvních sedm řádek a poslední řádka, čili osm řádek ze 44.

Je to vážně subjektivní – v Pythonu jsou chybová hlášení standardně dost ukecaná, v Perlu dost stručná. Na opačné chování jde v obou případech snadno přehodit. Perlové výchozí chování mně osobně připadne mnohem funkčnější.

Jak vas tak vsechny ctu, tak jsem opravdu rad za to, co mam od Sunu v konzistentni podobe.

30: že uft-8 šetří paměť je bez diskuse. nicméně k tomu bych dodal jeden poznatek ze své dvacetileté praxe. nesmyslné šetření pamětí bylo vždycky zdrojem těch největších problémů a posléze generátorem těch největších nákladů. šetřit paměť (stejně tak jako optimalizovat na jiná kritéria) je užitečné jen tam, kde to má smysl.

jen připomenu - celý humbuk kolem Y2K a miliardové náklady není nic jiného, než důsledek ušetření několika bajtů

Unicode - už tehdy když Unicode zavedlo dvoubajtové znaky mi došlo, že je to jen začátek dalšího průšvihu ve stylu nemístné šetření paměti. vývoj mi dal za pravdu, záhy se zjistilo, že to nestačí a rozšířilo se to na 4 bajty a teď máme ty důsledky. zbytečné kódování utf-16, které nasbíralo snad všechny nevýhody, které mohou nastat. různé přepínací a speciální znaky, které jsou tu jen jako pozůstatek z bordelu, kdy Unicode chtělo fungoval na dvou bajtech. a navíc zbytečné omezení na 21 bitů jen proto, aby bylo možné vůbec utf-16 a přepínací znaky udržet ve funkčnosti.

nic nenadělá větší bordel, než nesmyslné šetření paměti tam, kde to není potřeba. ale teď vám rozdávám svoje know how, ke kterému jsem se musel tvrdě dopracovat a nabít si několikrát velmi tvrdě čumák. takže raději mlčím.

28 a 32: Nechme Perl Perlem, o ten tu vůbec nejde. Jde o chybová hlášení.

Python může donutit k jakým chybovým hlášením chcete. Můžete ošetřit chybu kdekoliv v kódu, takže pokud program ví, že se s chybou umí vyrovnat, není důvod, aby se to za chybu vůbec považovalo. Protože v Pythonu nejsou a neexistují chyby, jen výjimky.

Nerozumím Perlu natolik, abych mohl cokoli prohlašovat o hlášení chyb, ale pochybuji o tom, že s chybami umí vyrovnat způsobem možným v jakémkoli programovacím jazyce založeném na výjimkách. Tak tu předveďte ukacené Perlovské chybové hlášení, rád se poučím.

S tím souhlasím do puntíku. Je to malá tragedie, že když už se vytvořilo nové kódování, na které bylo potřeba předělat všechny aplikace, vytvořilo se blbě a musí se to teď lepit.

35> Myslím, že si radši budu hlídat své pracně získané know-how.

37: Ok, beru na vědomí, že to Perl nedokáže.

> Vnitřní ukládání řetězců v utf-8. Ok, jako z
> nouze ctnost, proč ne? utf-8 je dobrý formát
> na import/export, ale zpracování řetězců
> vnitřně je mnohem lépe provádět v nějakém
> kódování s pevně danou šířkou znaku.

Jednomu nerozumim - namital jste, ze Ruby nema plnou podporu pro Unicode. A potom tu rikate, ze na nizsich urovnich by unicode naopak NEMEL podporovat... To mi spis pripada jako kdyz rikate, ze by programovaci jazyk nemel mit plnou podporu Unicode a nemel by ho cpat do vsech urovni (coz samozrejme klidne muze byt pravda, ja jen rikam, ze to nechapu, ne ze s tim nesouhlasim).

Ale nevim, jak by programovaci jazyk mohl pracovat s fixnim kodovanim (tedy alespon ne dnes, kdyz se jako znak bere neco jineho nez ASCII) - to nutne v nekterych pripadech ztrati nejake znaky (pokud budu pouzivat vic nez 256 ruznych znaku u 8-bitovych kodovani nebo znaky mimo BMP v UCS-2).

Jinak nazor "jeden znak = konstantni pocet bytu" mi pripada jako neco z 80. let...

dgx > neco podobného (ovšem přehlednějšího)
dgx > jsem si musel do PHP dodělat.

Je to neco sofistikovanejsiho nez vyuzivani v PHP funkce debug_backtrace()? Nedavno jsem si s tim taky hral, kresli mi to obdelnicky se jmeny funkci a mezi nima sipky znazornujici, co kam putuje. Az mi pripada jako skoda, ze to bezni uzivatele neuvidi :-)

39: Prosím Vás, kde jsem napsal, že na nižších úrovních by Unicode neměl podporovat?

Jeden znak = konstatní počet bajtů mi přijde pro vnitřní reprezentaci Unicode jako nejlepší varinata. A jaké znaky se ztratí, když budu Unicode vnitřně ukládat co znak to 4 bajtová hodnota?

utf-8 bylo vymyšleno pro dva účely:

1) jako formát pro přenositelné ukládání dat do externích souborů

2) jako nouzové řešení pro případy, kdy jazyk, nebo knihovna neumí pracovat s řetězci jinak, než jako s bajty. zdůrazňuji NOUZOVÉ ŘEŠENÍ.

jinak utf-8 není ani pro šetření pamětí, protože se klidně může stát, že řetězec v utf-8 zabírá víc paměti (tedy bajtů), než řetězec uložený tak, že každý znak konstantně zabírá 4 bajty. protože v utf-8 každý znak zabírá podle situace jeden až šest bajtů

zoule, ^C je v Pythonu normální výjimka, která se obsluhuje stejně jako ostatní výjimky a standardně vypisuje zásobník jako všechny ostatní výjimky. Nevidím žádný důvod, proč by se pro každou výjimku mělo definovat nějaké speciální chování a proč by systém za mě měl rozhodovat, kdy považuju výpis zásobníku za vhodný a kdy ne. Kolik úrovní výpisu zásobníku se mi hodí, záleží čistě na aplikaci a nevidím důvod si to přepočítávat. Perl v tomhle asi zrovna neperlí, když tu svoji metodu výpisu považujete div ne za námět pro SW patent. Na Pythonu je fajn, že člověk podobné věci nemusí pracně objevovat, ale fungují "out of the box".

Bote, public static void main system.out.println "tak si tu ukecanou javu užijte, když jste masochisti".

ahojky vy 18+ nevite kde je mozne se dozvedet o prg. jazyku Pythonu ( je mi 10 a chci se ho ucit doufam ze mi pomuzete... )

Potřeboval bych něco na středně velké aplikace a kolem Pythonu a Ruby on Rails chodím už dlouho jako mlsná kočka. Nicméně tahle diskuse mě zase jen potvrdila, že zatím není jiná cesta než se trápit s Php nebo dezertovat k Microsoftu - jenže tam jsem už byl.

Píšu tutorial na téma Ruby on Rails na http://rails.jinak.cz a jelikož mi chybí zpětná vazba snažím se tímhle příspěvkem nalákat nějaké čtenáře i k sobě.

Není to nic mega ultra cool, spíš si sám utřiďuji to co se zrovna učím. Žádné 20 leté zkušenosti děrnými štítky ošlehaného vývojáře.

Sice už to tu trochu zatuchlo, ale rád bych sem vnesl nějakou další alternativu. Co Java? Máte někdo zkušenosti s novým J2EE (~konec 2007) i s nějakým skriptovacím jazykem? Já zatím přecházím (možná) z PHP na J2EE, a zatím jsem jedině spokojený (až na problémy s classloadery).