V každé databázi jde zkonstruovat nebezpečný příkaz, v naprosto každé. I
té vaší dospělejší databázi. Je to o to snažší, že jen málokdo zná
úplnou syntaxi SQL pro daný databázový stroj, a jeho zákoutí. A databáze
nic nekontroluje, pro ní tím, že jste se přihlásil, a tím, že máte
potřebná práva
Dobrý den,
pomocí py2exe.
Nejjednodušeji to lze takto:
1) Vytvoříte soubor setup.py, který může vypadat asi takto (verze pro
konzolový program):
--- obsah souboru setup.py --(zde odstřihněte :-) )-
from distutils.core import setup
import py2exe
setup(
options =
Daleko důležitější FAQ: py2exe je prasečina, která prostě jen natvrdo
prohledává řádky s import a vkládá je do souboru.
Důsledek 1: Pokud někdo importuje dynamicky, pak py2exe to nezjistí a
modul do exe nepřidá a je třeba mu to ručně říct, že tam patří.
Důsledek 2: Pokud je někdy v podmínkách
A nedá se jednoduše nastavit souboru příznak pro propůjčení práv roota?
Miloslav Ponkrác
Jan Fuchs napsal(a):
Zdravím,
sudo samozřejmě uspěje i u lidí, jak říkáš: konzole se štítících.
a) pomocí příkazu visudo přidat následující řádek do /etc/sudoers:
brachaALL=(ALL)
Ano a od toho existují synchronizační objekty, jako jsou mutexy,
semafory, události, a řada dalších. Kromě toho se dá thread
synchronizovat asi tak padesáti tisíci způsoby šikovným využitím
přirozeného pozastavování threadů při různých operací jádrem operačního
systému a řada dalších triků.
Ještě bych chtěl upřesnit, že uspání pomocí sleep nezatíží procesor
vůbec. Po dobu uspání thread nedostává procesorový čas, a tudíž nikterak
procesor nezatěžuje. Pokud je skutečně Vaším cílem počkat 10 minut, pak
sleep je to nejlepší možné řešení, které můžete použít. Pokud je Vaším
cílem
Zdravím...
...a zcela nesouhlasím. Návrhové vzory jsem nikdy neměl
rád protože jsem zastáncem toho, že je vždy třeba
Sice souhlasím s tím, že návrhové vzory jsou jen berlička pro Ty, kdo
nemají cit pro návrh architektury, a že i bez nich se dají objekty
konstruovat. Že stejně většina
Dobrý den,
přímo se nabízí každé třídě vyhradit speciální metodu, například
getCommandText, která vrátí text, na který se reaguje. Případně to může
být i property CommandText.
Miloslav Ponkrác
Martin Stiborský napsal(a):
Zdravím, opět bych vás rád poprosil o vaše rady a zkušenosti.
Jde o
A je Vám známo, že všechny grafické knihovny jsou dělány na jedno
vlákno? A že neumí korektně zacházet s tím, když jim ve více vláknech
ovládáte grafické objekty? A pokud ano, tak se to musí speciálně
ošetřovat, a není to úplně snadné?
Ono totiž udělat multithreadovou knihovnu nese značnou
Ano, přesně tak. Tímto u mě superman ztratil důvěru. Důvěrou myslím, že
když něco nebudu vědět, a budu se muset spolehnout na můj úsudek, odhad
či intuici, raději se přikloním k názoru opačné strany. V tomto případě
tedy důvěřuji více Guidovi než jemu. Tím samozřejmě neříkám, že
možností oproti DB API u MySQL databáze. Každopádně moc děkuji
za tip.
Miloslav Ponkrác
Věroslav Kaplan napsal(a):
2008/6/28 superman [EMAIL PROTECTED]:
Dobrý den,
když pracuji s MySQL v Pythonu, tak obvykle přes standardní DB API
Pythonu. Bohužel MySQL je v leččems trochu nestandardní a řadu
On je základní problém, že databáze jsou relační, zatímco neustále se
různé frameworky snaží z toho udělat objektový přístup. A rozdíl mezi
těmito dvěma pojetí je tak značný, že objektový přístup nemůže být
efektivní.
Ale zase - každý luxus něco stojí a je třeba vědět, zda se vyplatí, nebo
Wrapper a interface je obrovský rozdíl! Interface je jen způsob
komunikace mezi dvěma systémy, tedy dá se říct virtuální popis toho,
jak se bude komunikovat. Wrapper je zase převodník, nebo jak se v hw
světě říká redukce z jednoho interface na jiný interface, a není to
popis, ale implementace
Stále mě nabádáte, abych si našel nějaká fakta. Taky byste to měl
někdy zkusit. Ale souhlasím s tím, že by Python mohl běžet ještě
rychleji, což dokazuje třeba Psyco.
Já to zkusil, právě proto píšu to co píšu. Navíc pomalost Pythonu je
logická už z principu jazyka a z principu runtime.
[EMAIL PROTECTED] napsal(a):
Pravdu nemá nikdo, je to pouze věc názoru
Ovšem je velmi pošetilé pravdu dokazovat na základě nás mnógo. Buďte
si jistí, že i když se celá komunita na 100% sjednotí na tom, že
gravitační konstanta bude 30, že realita se tím řídit nebude :-)
Miloslav
Dobrý den,
když pracuji s MySQL v Pythonu, tak obvykle přes standardní DB API
Pythonu. Bohužel MySQL je v leččems trochu nestandardní a řadu věcí je
lépe dělat přes nativní API. Existuje pro Python nějaký wrapper pro
nativní API, nebo jiná knihovna? Možná jsem špatně hledal, nevím...
Děkuji
Pavel Kosina napsal(a):
superman napsal(a):
Ano jsou. Stejně tak jako reakce na Hitlera u miliónu Němců byly také
povětšinou pozitivní například.
Ale no tak. Já vím, je to těžké, když ostatní nechápou moji pravdu, ale
toto prosím ne. Stačí.
Ale no tak. Jasně jsem
C++ je! pokračovatelem C. Přirozeným, nebo nepřirozeným ale je. Že se
Stroustrup nechal inspirovat jinými jazyky je tak nějak jasné. Protože
proto asi C měnil, že nemá objekty, že nemá proudy a tak.
A C++ je zpětně kompatabilní, zvláště u vás mě překvapuje, že tvrdíte
opak. Rozdíl je pouze v
V C++, dycinky v C++. :-)
Miloslav Ponkrác
Bystroushaak napsal(a):
OT: Můžu se zeptat v jakém jazyku se doplňky do FF píšou?
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Ano, jak tu někdo uváděl - záruky jsou někdy buzzword.
Nicméně této změně rozumím, protože je to snaha optimalizovat Oracle na
lepší výkon.
Myslím, že už jsem to tu někdy napsal - jakmile potřebujete
optimalizovat na rychlost, jde všechno hezké stranou - udržovatelnost,
kompatibilita,
taktiez ma zaujima, ze ci windowsovski programatori robia v nejakej
multiplatformovej kniznici, alebo v niecom cisto len pre windows?
He he, he he. Typický Windows programátor moc v Pythonu nepíše :-) A
pokud ano, tak většinou nasadí wxWindgets a opovrhuje Qt, protože
Windows
Python je jazyk, který se používá v rychlostně kritických aplikacích. Né
úplně doslova, nejnáročnější komponenty se píší v C případně C++ a Python
slouží jako nástavba pro rychlý vývoj s těmito komponentami.
Sám to popíráte - Python se nepoužívá v rychlostně kritických
aplikacích,
Asi to chce obecnou radu:
1) Programování her chce jiné věci, než programování grafických aplikací.
2) Programování grafických aplikací v herních knihovnách je ukrutně
pomalé a výsledek je hnusný.
Závěr: Na používání her se většinou používají dost odlišné knihovny
oproti programování běžných
Já osobně bych panu Rossumovi doporučoval, aby ideálně každý měsíc
neustále něco z Pythonu vyhazoval, aby držel programátory ve střehu.
Není nic zábavnějšího, než když se Vám nekompatibilně mění syntaxe
jazyka pod rukama. Programátor si nemůže přát nic lepšího, než po
večerech místo času s
A nestačí použít validátor odkazů, který je na strákách W3C komise?
Podle mě funguje dost dobře a proč ho nahrazovat?
Miloslav Ponkrác
Ondrej Beranek napsal(a):
Jde mi o to, ze chci udelat kontrolovatko platnosti odkazu uvedenych
na strance. takze najedu na web, skript si aktualni stranku
Ač tvé pocity mohu chápat, rozumím i pohnutkám Guida. A na druhou
stranu, jestli jsem to tedy pochopil správně, tak všechny tyto změny se
netýkají pythonu. Ale pythonu 3000. Což mi přijde naopak velice
sympatické. Je zde jasná hranice. Kdy na jednu stranu není svazován
nutností o
Jen bych doplnil, že Python 2.6 umožní zobrazit upozornění při použití
konstrukcí nekompatibilních s Python 3000, tudíž přechod bude velmi
příjemný a lze se přizpůsobit průběžně.
A taková otázka: Jak je to s kódy, které vývojář napsal před 2.6? Oni
Pythonisti počítají pouze s tím, že kódy
Jak dlouho? Jak dlouho bude k dispozici starší Python a všechny knihovny
ve verzích ke staršímu Pythonu? Opravdu si myslíte, že to někdo bude
dlouho udržovat?
Miloslav Ponkrác
Ja teda nevim, ale preci neni problem provozovat vice verzi python. Tak se
proste starsi kod pusti pod starsim
Má svojí hračku a chce si hrát - to je hlavní pohnutka pana Guida. A
protože je mu jasné, že tuhle pohnutku by Pythonistům říci naplno nemohl
- je třeba jí schovat za dobré úmysly. Třeba za to, že chce zlepšovat
Python, nebo jiné výmysly.
Miloslav Ponkrác
Jaké jsou to ty (tak důležité)
Proč by musel být každý projekt neustále přepisován? Ba právě naopak!!!
Betonově stabilní programy a kód získáte tak, že máte mnoho let
nepřepisované programy, do kterých se zasáhne jen v případě nalezené
chyby, jinak ne!
Dotaz: Jak moc byste věřili letadlu a byli ochotní s ním letět, kdybyste
Zajímavé je, že stálice a hvězdy na nebi programovacích jazyků jsou Ty,
které to nedělají. Evidentně Rossumův postup neprospívá jazykům.
Teoreticky si můžete myslet co chcete, ale v praxi se Rossumův postup
ukazuje jako spolehlivý postup, jak jazyk poslat do kolen a na dno.
Podívejte se do
Ano, a starší verze Pythonu bez toho, aby jí někdo udržoval bude běhat
na dalších verzích operačních systémů? Budou běhat s novějšími, i
budoucími verzemi databází? Internetových protokolů?
Ono je potřeba si uvědomit, že okolí Pythonu se mění a neudržovaný
Python runtime vyhodí ze hry coby
V assembleru neni moc co noveho vymyslet a i ostatni se vyviji. Vzdy
Python se od ostatnich jazyku co do vyvoje nikdy moc nelisil, proste sel
svouji cestou vyvoje. Jedinne co je jinak je proste chut udelat cistku.
Assembler se dost vyvíjí :-) Divil byste se, jaké změny jsou teď právě
na
Měl bych tu přirovnání: C a C++. Ačkoliv C++ je zpětně kompatabilní,
není zcela. Některé Cčkovské konstrukce v C++ použít nemůžete.
C a C++ jsou dva různé programovací jazyky. Nechápu, proč srovnáváte
kompatibilitu mezi nimi. Srovnává snad někdo kompatiblitu Javy a Pythonu
třeba?
superman wrote:
Dotaz: Proč v kosmonautice se stále používá 20 i více let starý hw
Protoze jsou zname jeho chyby a napr. odolnost proti ruznym formam
kosmickeho zareni.
Jinak řečeno, přepisování hw/sw by nebyla v tomto případě moc výhra.
Kdyz uz jsme v tom, tupe
Ale hlavně nechápu, že vám nevadí, že se nekompatibilně změní
databáze, internetové protokoly, atd., ale že se vyvyne a změní taky
Pathon je problém.
Ano? Já tedy nevím o databázi, která by nekompatibilně změnila API, nebo
SQL. Stejně tak nevím o tom, že by se TCP/IP protokoly nějak
Ale nikdo nikdy linux kernel nepřepsal, a stále je tam obrovská spousta
věcí z prvních dob. Přepisuje se jenom část a také se přidávají nové
featury.
No, kdyz ma napr. patch na 2.6.25 oproti 2.6.24 50MB(!), tak tomu nemohu
rikat stabilni SW :).
Ani pokud by třeba (teď vím, že
Jan Bednařík napsal(a):
Dne 25. červen 2008 18:22 superman [EMAIL PROTECTED] napsal(a):
Ale hlavně nechápu, že vám nevadí, že se nekompatibilně změní
databáze, internetové protokoly, atd., ale že se vyvyne a změní taky
Pathon je problém.
Ano? Já tedy nevím o databázi, která
Mám tři otázky:
Četl jste, jaké změny se chystají (všechny)?
Víte o existenci Python 2.6 a máte představu o tom, jak by měl
probíhat přechod na Python 3000?
Když už se dělá spousta zásadních a užitečných změn, které nejsou
zpětně kompatibilní, je takový problém, když se přitom udělá pár
A Blesk, Spy a Aha čte nejvíce čtenářů ze všech plátků, takže jsou to
analogicky podle Vaší argumentace nejkvalitnější a nejpravdivější noviny.
MySQL není profesionální databáze, to je nad Slunce jasné. Stačí, když
si s nějakou skutečnou databází něco začnete a pochopíte.
Mimochodem, já jsem
Stačí soubor přejmenovat - změnit mu příponu a dojde. Myslím, že kdybych
sám vytvářel projekt podobný gmailu, udělám totéž - zakážu spustitelné
přílohy. Po zakázání spustitelných příloh mail server přestane být
lákavým cílem pro obrovské množství spammerů. Pro ně je mail server na
nic, když
Já jsem si na escapování uvnitř SQL řetězců napsal vlastní Python
funkci. Je to velmi jednoduché, stačí si otevřít MySQL manuál a
zjistíte, že několik málo znaků je potřeba nahradit jinými řetězci,
takže to byla rychlovka.
Pravda, nejdříve mě zklamalo to, že jsem v Pythonu nenašel žádnou
Prepared statements byly původně zamýšlené pro opakované posílání
stejných SQL příkazů, které se liší jen v několika konstantách. Výhodou
bylo, že databázový stroj je jednou zparsoval, a jednou pro ně zpracoval
prováděcí plán a při opakovaných provedeních pak pouze rozjel akci bez
zdržování.
[EMAIL PROTECTED] napsal(a):
Já osobně doporučuji nepoužívat mail od volny.cz ale od seznam.cz kde je spam
filtr samozřejmostí.. A chyba není u tebe ale na py.cz kde by měl být spam
filtr...
Myslíte ten seznam.cz, který má velmi často výpadky a technické
problémy, a když někomu mailuji
Tak nikdo jiný, než seznam.cz nemá tak časté technické výpadky jako
seznam.cz, co se týká mailových serverů.
Jinak já používám primárně gmail, a jestli je JavaScriptový mě je jedno,
protože s maily pracuji normální mailovým klientem (tedy běžný
programem) přes POP3/IMAP protokoly a webové
2) trosku offtopic: nemali by sa potom prepared statements pouzivat jako
normalne v PHPcku? preco kazdy(koho poznam) pouziva miesto toho radsej
addslashes()?
Prepared statement nejsou náhrada escapování znaků v SQL stringách. K
tomu neslouží a nikdy nesloužily. Pokud se tak používají, tak to
MySQL - byla běžně 10x rychlejší v databázových operacích,
než MySQL. A to ještě Sybase ASA není nic moc v databázovém světě.
Miloslav Ponkrác
Jan Kundrát napsal(a):
superman wrote:
Jinak odpověď je to také otázkou zvyku. MySQL velmi dlouho prepared
statement vůbec nepodporovala, a mysql
Děkuji náčelníku, že jsi se mě zastal :-) Já osobně si myslím, že
get/set metody v Pythonu je absolutní pitomost, a že to tak krásný a
schopný jazyk, jakým Python je opravdu nemá zapotřebí. Nevidím jedinou
výhodu používání get/set metod v Pythonu - ani jedinou, kromě toho že
správný Javista
Zdravím,
dnes se naprosté základy programování prakticky nikde nevysvětlují,
zatímco dříve bylo knížek na každém rohu. Je to tak, že dnes se zavádí
přístup nepotřebujete to vědět a zbytečně by Vás to zatěžovalo.
Chtěl bych Tě podpořit, vytrvej, bude to ok.
Ale trochu jsem se podivil nad tím,
Já osobně bych dal přednost knihovně, která Vám dává nejvíce svobody, a
to Qt rozhodně není. Pokud už se člověk má učit nějakou knihovnu, měl by
v rámci maximalizace užitečnost/námaha dát předsnot něčemu, co může
použít všude. Qt knihovně je licenčně velmi omezena, kde jí smíte použít
bez
A proč se má člověk učit dvě knihovny? Jednu pro komerční, a jednu pro
open source? (Mimochodem, Qt nemůžete použít pro open source, ale jen
pro open source s přesně určenými licencemi, zejména GPL - tedy tvrzení,
že u open source nemusíte licence Qt řešit je lež jako věž.). Proč mám
No vidite, a prave tohle prijde nelogicke zase mne. Pokud predefinuji
tridu str, cekal bych, ze dalsi instance teto tridy bude pouzivat moji
customizaci.
Nerikam,ze je takove chovani prakticke, kazdopadne priklad, ktery jsem
pred par dny konstruoval mel ukazat, ze ona jednotnost
Dispatcher (server), ktery spousti nekolik tisic vlaken si vytvori
vlastni registracni strukturu metadat o kazdem z pustenych vlaken,
kteremu pri startu (pokud je to nutne) preda referenci na jeho zaznam.
Zde muze byt napriklad struktura semaforu, pripadne jineho
synchronizacniho
slush napsal(a):
Není v programování nic horšího, než předsudky.
Tak az po tenhle bod jsem celkem souhlasil. Pokud to myslite tak, ze
trpim nejakymi vyraznymi predsudky (napriklad vuci globalnim
promennym), musim Vas zklamat
Nic takového jsem netvrdil. I když diskutuji s Vámi, tak
Boa constructor je ale úzce svázaný na tento tool. Generuje přímo třídy
a objekty. Tudíž to co si naklikám mohu použít jen a pouze pro python.
To nemluvě o skutečnosti, že když jsem Boa constructor skoušel tak se
choval poněkud nevyzpytatelně.
Mám pocit, že v této konferenci se mluví o
Globální proměnné nejsou prasení v rozumném počtu. Stejně tak jako
leccos dalšího.
V tomhle si dovolim nesouhlasit. Pokud programator potrebuje pouzit
globalni promennou, udelal v navrhu datovych struktur chybu.
Já tenhle názor nesdílím. Globální proměnná je zkrátka jenom datová
python jen dela, ze string je class
To je úplně v pořádku co programovací jazyk předstírá, protože
programovací jazyk je tu od toho. Programovací jazyk je jen syntaktický
cukr nad stroják, nic jiného.
class str(str):
... def zzzmojefce(self):
... return blabla
...
Já bych tohle rozhodně přečíst nedoporučoval, zlváště pokud to odkazuje
na lživé materiály. Kniha Dark side of C++ je nepravdivá, autor této
knihy nemá ani elementární znalosti o C++, a obsahuje spoustu faktických
chyb a nepravd. Nemám důvod si myslet o autorovi, který doporučuje
lživou knihu,
Já mám vůbec averzi ke všemu co potřebuje lhát pro své argumenty, a
takové materiály i osoby na mě působí velmi nedůvěryhodně. Buď mám
dobrou myšlenku, a pak se obvykle nepotřebuji uchylovat ke lhaní, a nebo
mám myšlenku, které nevěřím, a pak se bohužel spousta lidí uchyluje ke
lhaní a
degenerovanost :-).
Jinak ale souhlasim v tom, ze C++ rozhodne neni jazyk pro zacatecniky.
Marek
2008/6/5 superman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
K obsahu [2] nemám co dodat, neboť postscript je pro mě nečitelný - a
instalovat ghostscript nehodlám kvůli jednomu postscriptu
Přesměrovat výstup do roury a tu rouru číst, tedy pokud program vypisuje
na stdout, nebo stderr. Pokud vypisuje natvrdo do konzole, pak smůla.
sedo sedo napsal(a):
Zdravim,
mam takovyto problem. Delam GUI pro jeden script, ktery vypisuje na vystup
procenta sveho behu ve tvaru 0..10..20..30
Obávám se, že jste narazil na limit programovacích jazyků, které dělají
věci automaticky. Prakticky v žádném jazyku, který striktně paměť řídí
garbage collectorem není 100%ní kontrola uvolňování objektů.
Můžete zkusit modul gc a metodu collect, případně nastavit meze
(thresholds) pro všechny
Takze pokud nejaky vypocet uzira pamet a zadne cisteni objektu
nepomaha, hledal bych vinika jinde. Predpokladam, ze vypocty ve SciPy
jsou kvuli optimalizaci psany v Ccku a jak se vsichni shodneme, napsat
pametove neprustrelny C kod vyzaduje zkuseneho programatora. Takze bych
spis ocistil
Spíš mám pocit, že dnešní jazyky jsou dneska všechny na jedno brdo. Že
každý jazyk má jinou syntaxi plus pár vychytávek a zbytek už je stejný.
Takže nic nového se neděje. Strašně rád vzpomínám na svá studia cca před
15 lety, kdy jsem se seznamoval s programovacími jazyky, které měly
šťávu a
zu1234 napsal(a):
1) Vidím určité rozdíly mezi Temelínem a příručkou.
Zdají se mi nezanedbatelné.
Morava nezvládá příliv ozářených utečenců!!!
Čechy vylidněny pythonovým spadem!!!
Pythonový spad je svinstvo. Dnešní lékařská věda proti nezná obrany!
2) Už minule jsem psal že nemíním
slush napsal(a):
Jinak řečeno, nevíme co máme dělat, ale vytyčme jak to budeme dělat.
V této fázi na tom nevidím nic špatného. Diskuze o obsahu je
samozřejmě nutná, to nezpochybňuji, ale myslím, že bude efektivnější,
když budeme diskutovat (iterativně) nad jednotlivými body (bod =
slush napsal(a):
superman napsal:
A pak zapomínáte na obrovskou výhodu kolektivní práce,
kterou jako osoba nemáte. Jako osoba, když něco nezvládnete, máte
smůlu.
Jako kolektiv můžete selektivně přitáhnout ty lidi, kteří zvládnou
to co
je potřeba.
Já na to naopak
Ano a to je to co jsem napsal jako, že je nutné udělat osnovu. Jinak
Nikoliv, Vy pořád chcete slyšet bude to pro geeky, bude to pro
začátečníky. Konkrétních návrhů na obsah tu už několik bylo. Problém
je, že to ty lidi napsali jen do diskuze, zapadlo to - Protože v tu
chvíli
superman je prostě
nesmysl. Kolektivní práce tak nefunguje, cokoliv se může kdykoliv
změnit/upravit, pokud se najde někdo, ochotný dopsat zajímavou
kapitolu a ostatní s tím budou souhlasit.
Proč je to nesmysl? To za prvé a za druhé nikdo o zakonzervování
nemluvil.
Minimálně
U kolektivní práce je to obráceně. Až na možné výjimky se neznáme,
nevíme, kdo je na jaké úrovni a kdo co zvládne. Proto je potřeba začít
z druhé strany - připravit si zázemí a zkoušet, co nejlepšího z nás
může vypadnout nějakým iterativním způsobem. Někdo například navrhne
určitě velmi
slush napsal(a):
Já to vidím přesně obráceně. Vytyčme:
a) technologie (např. wiki - latex - PDF)
b) způsob komunikace (např. IRC kanál pro online diskuzi nad
problémem, samostatnou web-based diskuzi o jednotlivých
kapitolách/tématech, komentování konkrétních textů v diskuzích na wiki)
c)
Můj osobní názor je, že psát knížku v angličtině o Pythonu je blbost.
Sice nemám problém jí v angličtině číst, ale není důvod.
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Nevýhoda všech knížek tohoto zaměření je v tom, že ještě než ji vydáte,
už je vlastně zastaralá :-(
Přesto, že základy se obvykle nemění, u Pythonu toto nebude tak docela
pravda, protože Py3k dost věcí mění (třeba jedna nejzákladnější funkcí
print). Pokud se někdo chce do takového
Znovu se ptám, pro koho ta kniha bude a čím se přesně bude zabývat? On i
dům se staví od základů a nadšení je hezká věc, ale dům od střechy
nepostavíte.
[EMAIL PROTECTED] napsal(a):
Hmm, napadlo mně že by třeba stálo za to napsat celou tu knihu na py.cz -
napsat články do wiki a ty pak vydat
Prostě a jednoduše by se mi líbilo, aby to byla kniha, kde si každý
najde to svoje. Ať už se jedná o začátečníka, nebo někoho kdo už umí
programovat. Stejně tak aby ten, kdo umí hlavně webové záležitosti se
naučil něco o psaní pod gtk/wx/qt.
No to je právě utopie. Univerzální kniha (která
taktiez by som poprosil vyvarovat sa stylu pisania a la Mistrovstvi v
C++(dlhe pre zaciatocnika nepotrebne a nidne veci), lebo to som asi po
tyzdni vzdal(druha vec je, ze po roku to zacinam ocenovat, ale na zaciatok
fakt ludi nezaujimaju vsetky detaily...) :-(
Jsem lékař a chci léčit
Pro koho má kniha být? Určitě by to neměla být učebnice programování.
Čtenáři by už měli mít zkušenosti s procedurálním i objektovým
programováním. Ať už na teoretické úrovni nebo třeba v php. Dneska už na
střední možná základní škole se dají nějaké základy programování
pochytit. Tj. probral
{zde vložte příspěvek páně Supermana, který bude jistě následovat,
přičemž nepochybuju, že bude poučný;)}
Tak teď jsem se nasmál, tohle jsem nečekal.
On je Python a C++ tak odlišný, že se to nedá srovnávat. A Qt byla
původně pro C++. Navíc pro C++ je problém, že kromě všeho musíte taky
A pana Supermana bych (opakovane) pozadal, aby se venoval vice samotne
podstate (technickych) skutecnosti a jejich vyklad ponechal na jednom
kazdem laskavem ctenari.
Sice mám pocit, že se víceméně snažím mluvit k tématu. Uznávám, že mám
občas grafomanské sklony a stručnost není mojí silnou
Odstřelení threadu se obecně lidi brání, protože to je dost drastická
věc, která mimo jiné může uvést i Váš program do neschopnosti dál
pokračovat. Uvědomte si, že každý thread má svůj zásobník, a při
násilném odstřelení threadu operační systém většinou zásobník neuklízí,
ale nechá ho jakožto
Já osobně tyto konstrukce používat nebudu. Sice jsem o nich ani nevěděl,
a jak vidím, vůbec to nevadí. Vidím, že made by Python inventor
opravdu už začíná poněkud poněkud. Zlaté dobře čitelné Céčko! Zatím jsou
nové konstrukce podmíněného přiřazení v Pythonu a tato konstrukce else
po cyklu mým
oprava - ve větě: Zatím jsou nové konstrukce podmíněného přiřazení v
Pythonu a tato konstrukce else po cyklu mým soukromým kandidátem na
najpřehlednější existující zápis ze všech programovacích jazyků, co jsem
za cca 20 let své praxe poznal.
Správně má být slůvko NEJNEPŘEHLEDNĚJŠÍ, ale to asi
Já to nikomu neberu, klidně si to používejte do libosti, a vyjádřil jsem
svůj názor, který samozřejmě nevydávám za pravdu (ostatně tady se ani k
pravdě dobrat nejde). Podle mého subjektivního názoru jsou to
konstrukce, která snižují čitelnost programu. Vlastně já už se ani
nesměju, když čtu
Ano, přenastavit celý stroj kvůli jednomu programu a zničit veškeré
upozorňování na vážné chyby uživateli je fajn řešení.
zu1234 napsal(a):
Moc Vám děkuji za ochotu to u Vás zkusit!
Ale řešením problému s
Exception Processing Message c013 Parameters 75b6bf9c 4 75b6bf9c
75b6bf9c
je
A mimochodem, jak byste to řešil Vy?
Uvědomil bych si, že přenositelně to napsat nejde a obalil bych si pár
Win API funkcí buď sám pomocí Python C API, nebo bych použil modul win32.
Pomocí Win API funkce SetErrorMode(unsigned int mode) bych nastavil
režim chyb, který bych chtěl pro svůj
Systémové message okno je reakce Windows na to, když si nenastavíte
vlastní režim ošetřování výjimek, a neodchytíte výjimku. To dělá každý
program. Vše je možné nastavit.
Jinak starý klasický trik je pokusit se otevřít soubor A:\NUL, který se
podaří otevřit, pokud máte v mechanice disketu.
Pri cteni mne napada otazka jak tedy psat programy?
Prostě Unicode nevyřešilo co mělo řešit. Ale alespoň udělalo jednu věc,
že osekalo počet nutných znakových sad, které potřebujete k tomu plně
vyjádřit pro všechny znaky - když jako jednu vezmete Unicode, pak pár
asijských znakových sad a
Přiznám se, že jsem to víc nezkoumal - a možná, že nebudu zcela v
obraze, ale měl jsem pocit, že plné zobrazení UTF-8 na Windows zařídit
nejde, a že vždy je riziko výjimky. Kdykoli narazil na znak, který nešel
převést do výstupní znakové sady terminálu, pak výjimka okamžitě
vystřelena. A že se
Jinak terminály pod Linuxem bývají dnes utf-8, pod Windows cp852, takže
Bohužel pro Windows není to pravidlo - možná v češtině ve Windows ano.
Takže kód počítající s tímto kódováním může taky špatně dopadnout.
Jinak do Windows konzole se dá psát jako ANSI řetězce, tak i Unicode
řetězce, tedy
Zdravim,
sice jsem tu jen pasivni prihlizejici, ale to vyuziti je nasnade,
protoze v promenne muze byt i nazev funkce $foo($bar), kde $foo udelam
nekde predem podle potreby jakou funkci potrebuju zavolat.
Ne, využití tohoto opravdu není nikdy potřeba pro běžný program. Vždy to
jde
Já bych řekl tak, syntaxe přirozená lidské řeči už tu byla - byl to
jazyk, který se jmenoval COBOL, a nepřejte si v něm programovat, je to
děs a hrůza. A taky tam vznikaly podobné patvary jako právě v
Pythonovském if přiřazení. Pro ilustraci, copak asi dělá - samozřejmě
v přirozené lidské řeči
Ten výraz
(b, 10)[b != 0]
není ekvivalentní zápisu ternárního operátoru v Céčku ani náhodou. Když
zapíšu výraz
podmínka ? expression_true : expression_false
pak dojde k vyhodnocení pouze jednoho výrazu, buď toho pro true, nebo
pro false část - což je velmi důležitá věc. Zatímco ten
A kde je problém?
Pokud znám políčka a strukturu předem, pouze vytvořím příslušnou HTTP
hlavičku následovanou daty s odpověďmi (viz specifikace HTTP protokolu)
a pošlu vše přes sokety na příslušnou IP adresu a port a rozeberu
vrácenou HTTP odpověď pro případnou kontrolu chyb. To je vše a no
v tom, že bych to rád viděl prakticky a nejlépe jako tutoriál, nejen
pro mne.
A má smysl psát tutoriál pro něco co není Python specific, ale je
nadjazykové - a je to běžně popsáno na webu?
___
Python mailing list
Python@py.cz
Pokukoval jsem po moznostech vetsich projektu. Narazil jsem napriklad na
web epoptavka.cz, kde firmy poptavaji podle meho zajimave ukoly, ktere
akutne potrebuji resit. Prohlizim i zahranicni burzy IT projektu,
napriklad getafreelancer.com, ale ten je preplneny Indy, kteri jsou (kdyz
to
Tohle snad opravdu není nutné řešit rekurzí, to zvládne jeden vhodně
napsaný for cyklus to co píšete.
Ale Vámi popsaná funkce samozřejmě errorem skončí, protože nemáte
podmínku k ukončení rekurze, dochází k nekonečné rekurzi a nekonečnou
paměť na stacku opravdu ještě žádný počítač nemá. Ta
A není tak, že kdo si chce zkompilovat vlastní verzi, by to měl umět, a
měl by si umět přeložit z angličtiny naprosto primitivní chybové
hlášení, které je tak jasné, že už jasnější být nemůže? Tedy člověk,
který posílá do konference s dotazem hlášku Python was built with
Visual Studio version
rejp
Na tomhle slabém hw se dá Vista použitelně používat?
/rejp
[EMAIL PROTECTED] napsal(a):
O Vánocích jsem dostal dárek a to knihu Začínáme programovat v Pythonu.
Snažím se podle ní učit, ale mám problém se zobrazováním češtiny na výstupu.
Snažil jsem se nastavit příslušné fonty, ale bez
Ještě bych chtěl napsat, že Python těžko kdy bude mít dobrý
optimalizátor a to z toho důvodu, že neustále mění syntaxi a neustále
mění interpretr i byte kód. Takže pokud by někdo začal, tak se na to po
několika restartech, kdy bude muset začít plus mínus znovy rád vykašle.
Optimalizátory pro
No pravda pokud je vynalozene usily nekonecne tak jiste neni problem ani
extremni varianta ze podle projevu to napisete znovu.
No v případě Pythoního byte kódu je potřeba celkem malé úsilí. Věřte mi.
Nikdy jsem to nezkoumal ale predpokladam ze compilator se hlavne snazi
optimalizovat a
1 - 100 z 185 matches
Mail list logo
