Re: [python] MySQL - nativní rozhraní pro Python
Mohl by, prosím, někdo začátečníkovi vysvětlit po-lopatě pojem 'wraper'. DB API chápu jako balík stejných fcí pro práci nad 'jakýmkoliv' databázovým strojem. ZU 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 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... _mysql je wrapper okolo C API, oproti tomu MySQLdb je wrapper na _mysql, abi odpovídalo DB API. Na mém stroji to vypadá, že obsahují různé symboly. Kvalitu modulu _mysql neposoudím, protože do C API MySQL nevidím, ale třeba to k něčemu bude. ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
To víte že to pomohlo - děkuji za velmi pěkné vysvětlení!! Takže hotový program v pythonu se skládá z python-jazyka a různých wrapperů pro to, co vlastní python neumí. Normálně bych tomu řekl mezi-ksicht alias interface. Díky! ZU Filip Štědronský napsal(a): On Po, čen 30, 2008 at 08:04:02 +0200, zu1234 wrote: Mohl by, prosím, někdo začátečníkovi vysvětlit po-lopatě pojem 'wraper'. Dobrý den, wrapper je doslava přeloženo obal, tedy sada funkcí/ tříd/metod/čehokoliv, která zapouzdřuje jinou sadu funkcí /metod/tříd/čehokoliv, poskytuje k ní jiné rozhraní. Je běžné, že když se píší moduly pro Python zapouzdřující existující (Cčkové, nativní, kompilované) knihovny, jako je GTK, MySQL client library, etc., napíše se v C (pomocí Python-C API, což je nevyhnutelné, neb není jiný způsob, jak propojit dynamický svět Pythonu s kompilovaným Cčkovým okolím jen jednoduchý obal Cčkovských funkcí, často 1:1 mapování C funkcí na Pythonské, protože psát moduly v C není dvakrát jednoduché. Ale jakmile je rozhraní knihovny jednou Pythonu zpřístupněno (byť ve své Cčkové ošklivosti) pomocí tohoto wrapperu, který obaluje původní funkce určitými rozhraními potřebnými k tomu, aby je šlo volat z Pythonu, není problém napsat další, vysokoúrovňový, objektový obal přímo v Pythonu (to již je snadné), který zapouzdřuje před uživatelem tyto jednoduché funkce a nabízí konzistentní a příjemné rozhraní. Taktéž se toho používá pro skrývání implementačních rozdílů (stejné rozhraní postavené nad několika různými moduly, např. zmíněné DB API) Doufám, že to pomůže. Filip Štědronský ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativn� rozhran� pro P ython
Taky diky za polopaticke vysvetleni. Tomas On 30.6.2008 10:03, Filip Štědronský wrote: On Po, čen 30, 2008 at 08:04:02 +0200, zu1234 wrote: Mohl by, prosím, někdo začátečníkovi vysvětlit po-lopatě pojem 'wraper'. Dobrý den, wrapper je doslava přeloženo obal, tedy sada funkcí/ tříd/metod/čehokoliv, která zapouzdřuje jinou sadu funkcí /metod/tříd/čehokoliv, poskytuje k ní jiné rozhraní. Je běžné, že když se píší moduly pro Python zapouzdřující existující (Cčkové, nativní, kompilované) knihovny, jako je GTK, MySQL client library, etc., napíše se v C (pomocí Python-C API, což je nevyhnutelné, neb není jiný způsob, jak propojit dynamický svět Pythonu s kompilovaným Cčkovým okolím jen jednoduchý obal Cčkovských funkcí, často 1:1 mapování C funkcí na Pythonské, protože psát moduly v C není dvakrát jednoduché. Ale jakmile je rozhraní knihovny jednou Pythonu zpřístupněno (byť ve své Cčkové ošklivosti) pomocí tohoto wrapperu, který obaluje původní funkce určitými rozhraními potřebnými k tomu, aby je šlo volat z Pythonu, není problém napsat další, vysokoúrovňový, objektový obal přímo v Pythonu (to již je snadné), který zapouzdřuje před uživatelem tyto jednoduché funkce a nabízí konzistentní a příjemné rozhraní. Taktéž se toho používá pro skrývání implementačních rozdílů (stejné rozhraní postavené nad několika různými moduly, např. zmíněné DB API) Doufám, že to pomůže. Filip Štědronský ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
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 - tedy skutečné provedení. Miloslav Ponkrác P.S.: Děkuji za odpovědi, právě jsem si je pročetl a budu zkoušet, a dám vědět :-) zu1234 napsal(a): To víte že to pomohlo - děkuji za velmi pěkné vysvětlení!! Takže hotový program v pythonu se skládá z python-jazyka a různých wrapperů pro to, co vlastní python neumí. Normálně bych tomu řekl mezi-ksicht alias interface. Díky! ZU ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
Ano, pane Ponkác, vaše definice je přesná. ZU superman napsal(a): 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 - tedy skutečné provedení. Miloslav Ponkrác P.S.: Děkuji za odpovědi, právě jsem si je pročetl a budu zkoušet, a dám vědět :-) zu1234 napsal(a): To víte že to pomohlo - děkuji za velmi pěkné vysvětlení!! Takže hotový program v pythonu se skládá z python-jazyka a různých wrapperů pro to, co vlastní python neumí. Normálně bych tomu řekl mezi-ksicht alias interface. Díky! ZU ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
2008/6/29 Jirka Vejrazka [EMAIL PROTECTED]: Možná to k ničemu nebude, ale přihodím trošku do mlýna :-) Momentálně na jednom projektu ke zjednodušení práce s databází (konkrétně MySQL) používám Django. Je sice určené na vývoj webových aplikací, ale vrstva která se stará o databáze je pro mé účely vyhovující a zbytek frameworku prostě ignoruju. Třeba to pomůže... Jirka Na to bych použil spíš SQLAlchemy, ale i ořezané Django může být příjemné řešení. Honza ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
Doufám že to někdo nevezme jako provokaci, ale opravdu by mi občas bodlo dostat se prostě do obrazu. Takže, byl by někdo ochotný obeznámit nás začátečníky s pojmy jako je SQLAlchemy a Django. Ale prosím opět polopatě a prakticky a lidsky. ZU Jan Bednařík napsal(a): 2008/6/29 Jirka Vejrazka [EMAIL PROTECTED]: Možná to k ničemu nebude, ale přihodím trošku do mlýna :-) Momentálně na jednom projektu ke zjednodušení práce s databází (konkrétně MySQL) používám Django. Je sice určené na vývoj webových aplikací, ale vrstva která se stará o databáze je pro mé účely vyhovující a zbytek frameworku prostě ignoruju. Třeba to pomůže... Jirka Na to bych použil spíš SQLAlchemy, ale i ořezané Django může být příjemné řešení. Honza ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
O SQLAlchemy nic psat nemuzu, nikdy jsem s tim nepracoval.
Django je framework pro psani webovych aplikaci (jeden z mnoha), ktery
mimo jine obsahuje funkcnost pro praci s databazi pythonovskym
zpusobem.
Tj. misto toho abych pracoval primo v databazovem jazyce SQL a psal:
SELECT ulice FROM adresy WHERE ulice LIKE '%Sokolska%'
nebo
INSERT INTO adresy (ulice) VALUES ('Sokolska')
muzu pracovat primo s objekty v Pythonu, tj. pouziju:
from app.models import Adresa
sokolska = Adresa.objects.filter(ulice__contains='Sokolska')
prvni_sokolska = sokolska[0]
posledni_sokolska = sokolska[-1]
Pokud chci neco ulozit do databaze, nemusim resit na urovni
databazoveho SQL jestli budu delat INSERT nebo UPDATE, proste vezmu
odpovidajici objekt a zavolam jeho metodu save()
prvni_sokolska.ulice = 'Sokolska_zmenena'
prvni_sokolska.save()
(tohle jsou _hodne_ zjednodusene priklady, pochopitelne)
Django umi pracovat s ruznymi databazemi na pozadi (predpokladam ze
SQLAlchemy taky). Pokud byste chteli pouzit Django jenom pro
zjednoduseni prace s databazi, je to asi spatny napad (ja to tak
delam, ale mam i jine duvody). Pokud byste chteli vyvijed webovou
aplikaci v Pythonu, stoji Django rozhodne za zvazeni (ale neni to
jedina moznost).
Vice se da najit na http://www.djangoproject.com/documentation/ nebo
na http://www.djangobook.com/en/1.0/ (ta se da koupit i v papirove
podobe). I u nas se par lidi pouzivajicich Django najde, viz
http://djangopeople.net/cz/.
Tak, a ted si pripadam jako bych Django prodaval a mel z toho provize ;-)
Jirka
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Re: [python] MySQL - nativní rozhraní pro Python
2008/6/29 zu1234 [EMAIL PROTECTED]: Doufám že to někdo nevezme jako provokaci, ale opravdu by mi občas bodlo dostat se prostě do obrazu. Takže, byl by někdo ochotný obeznámit nás začátečníky s pojmy jako je SQLAlchemy a Django. Ale prosím opět polopatě a prakticky a lidsky. ZU SQLAlchemy je aplikace, která ti umožní pracovat s tabulkami a záznamy v databázi jako s běžnými objekty. Je určena pro integraci do jiných aplikací, jako databázová vrstva. Nemusíš tak být odborník na SQL, aby jsi mohl jednoduše a pohodlně pracovat s databází, teoreticky ani nemusíš vědět, jak databáze fungují a co to SQL je. Koukni na http://www.sqlalchemy.org/docs/05/ormtutorial.html a pochopíš, oč jde. Django je RAD (Rapid Application Development) framework pro tvorbu internetových aplikací. Funguje na principu MTV = Model Template View. V první úrovni - Model - nadefinuješ modely. To jsou třídy reprezentující tabulky v databázi a jejich závislosti a pak s nimi pracuješ jako s objekty. Je to hodně podobné jako ta SQLAlchemy s hlavním rozdílem v tom, že nedefinuješ jen typické datové typy (varchar, int, atd.), ale můžeš použít i speciální jako EmailField, IPAddressField, apod., které jsou v databázi uloženy třeba jako obyčejný varchar, ale při práci mají speciální schopnosti, jako třeba že ten EmailField při přiřazení kontroluje, zda je hodnota platná e-mailová adresa. Teď trochu odbočím, ale musím prozradit jednu z bezkonkurenčních (pokud jsem dobře informován) výhod Djanga oproti jiným webovým frameworkům, a tou je automaticky generovaná administrace. Na základě zadefinovaných modelů generuje velmi propracované administrační rozhraní. Proto je tam taky spousta různých datových typů, které ve výsledku mají vliv jen na chování té administrace (různé formulářové prvky s JS/AJAX vylepšeními). A když jsou nadefinované modely, přide na řadu část View. To znamená nadefinovat šablony pro URL a k nim odpovídající view funkce, které se mají zavolat (dle potřeby s parametry získanými z URL). Tady je to hlavně o hraní s objekty modelů. Ve view získáš potřebná data, která se zpracují v poslední části - Template. Template jsou (X)HTML (nebo XML, nebo jakékoliv jiné) soubory, které obsahují speciální značky, které Django nahradí hodnotou z view. Pole hodnot vypíše cyklem. Aplikuje na hodnoty různé výstupní filtry třeba na pěkné zobrazení data či zaokrouhlení měny. A tak podobně. Je toho spousta, co by šlo o Djangu napsat, doporučuji ale rovnou zkusit. Je to zábava s ním pracovat. Ještě jsem si vzpoměl na jedno video z nějaké přednášky o Djangu, které stojí za to shlédnout http://video.google.com/videoplay?docid=-70449010942275062q=djangoei=7mhpSMG7Jpyc2wLx8dyoCg Honza ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] Guido o funkcich reduce(), filter() a map() v Python 3000
Musím Vás zklamat, Python je jeden z nejpomalejších interpretovaných jazyků. Je to daň za špatný runtime Pythonu (který neobsahuje téměř naprosto žádné optimalizace, a třeba JIT je zcela utopickým snem) a dále daň za velkou obecnost jazyka, která je velmi příjemná pro vývojáře, ale nese si svou daň ve zpomalení. Python je oborovský pomalík. 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. Problém je kdekoli, kde předěláváte produkční kód, není-li pro to vážný důvod. A problém je to proto, že to nikdy není zadarmo - vždy to hodně stojí - času, peněz, stability, a leččehos dalšího. U hotové aplikace není důvod ani potřeba nic přepisovat. Nevím, jakou máte představu o tom, jak přejít na Python 3000, ale nikdo netvrdí, že musíte ze dne na den přejít z Pythonu 2.5 na Python 3000 (klidně můžete zůstat na Pythonu 2.5 až do smrti, přítomnost Pythonu 3000 ho nezruší). U většiny aplikací, u kterých probíhá vývoj, při plynulém přechodu na Python 2.6 a pak na Python 3000 s využitím připravených nástrojů, žádné extra náklady navíc nevzniknou. Kolik procent projektů používá nějaký jazyk vůbec nic nevypovídá o kvalitě toho jazyka, viz. např. PHP. Důležité je na jaké projekty ten jazyk lidé používají. Vypovídá to ne o kvalitě jazyka, ale o komplexním součtu působení různých vlivů - kvalita jazyka, podpora vývojářů, dostupnost prostředků, serióznost tvůrce jazyka a jeho úcta k práci vývojářů a nebo neúcta pokud jim jazyk rozorává pod rukou, marketink, záruky, pověst, o tom, zda je to třeba nejlepší jazyk pro určitou oblast, atd. atd. atd.. Takže je těch vlivů tolik, že stejně nelze určit, proč je Python někdy populární více a jindy méně. Tohle je jen otázka úhlu pohledu. Co jsem tak různě pochytil tak reakce na změny v Pythonu 3000 jsou většinou pozitivní. Ano jsou. Stejně tak jako reakce na Hitlera u miliónu Němců byly také povětšinou pozitivní například. Tímto chci říct, že pravda není závislá na počtu jejích zastánců. A pravda se nedá odhlasovat. I v případě Hitlera byla drtivá většina lidí, kterých se jeho činy dotýkaly, proti. V demokratické společnosti platí názor většiny, a pokud je většina pro změny, nic s tím nezmůžete. Je to blbej systém, ale ty ostatní jsou jenom horší. Honza ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] Guido o funkcich reduce(), filter() a map() v Python 3000
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. Nicméně pomalost neznamená vadu, je to daň za jiné pěkné vlastnosti, za které se platí rychlostí. A pak také daň za neustálé překopávání jazyka - to je další negativní důsledek Rossumových akcí - kdyby Python byl stálý, věřím, že by někomu stálo za to vyvinout dobrý runtime pro Python spolu s dynamickou optimalizací (které v Pythonu není) a možná i JITem (která je nesplnitelným snem). Taková Java například to z velké pomalosti dotáhla na to, že v rychlosti čistého kódu se blíží rychlosti jazyka C. Je to důsledek vývoje runtimu, který trval mnoho let. Ale Python prostě musí mít špatný a pomalý runtime, protože při neustálém překopávání jazyka nelze naprogramovat nic složitějšího, než v podstatě primitivní runtime prakticky bez optimalizací. Lidé pořád zapomínají, že změna v jazyce znamená změny v obrovském množství kódu a nástrojů. U hotové aplikace není důvod ani potřeba nic přepisovat. Nevím, jakou máte představu o tom, jak přejít na Python 3000, ale nikdo netvrdí, že musíte ze dne na den přejít z Pythonu 2.5 na Python 3000 (klidně můžete zůstat na Pythonu 2.5 až do smrti, přítomnost Pythonu 3000 ho nezruší). U většiny aplikací, u kterých probíhá vývoj, při plynulém přechodu na Python 2.6 a pak na Python 3000 s využitím připravených nástrojů, žádné extra náklady navíc nevzniknou. Jednou Vás to donutí přejít - pokud jste trochu zběhlý v praxi, tak se prostě nedá časem nepřejít. Jednoho dne se objeví něco - nepodpora něčeho v okolí programu, která je jenom v nové verzi a přejít prostě musíte chca nechca. Proč nutně musí u aplikací probíhat vývoj? A to s těmi žádnými extra náklady je dobrá věta - na prvního Apríla. Ono totiž i když probéhá vývoj, tak v aplikaci jsou obrovské části kódu, na které se nesahá. To může být klidně i 90% kódu, které zůstávají beze změny. Mění se jen část projektu. Ty nezměněné části jsou odladěné, a je na ně spolehnutí. Ovšem při změně syntaxe jazyka musíte sáhnout na vše - na 100% kódu. Minimálně je otestovat - a jestli to neznamená dodatečné náklady navíc, pak jsem čínský papež. Takže je těch vlivů tolik, že stejně nelze určit, proč je Python někdy populární více a jindy méně. S tím nesouhlasím. Je rozdíl mezi tvrzením je tam hodně vlivů a tvrzení nelze určit, které vlivy to jsou. Vy jste dost nekorektně bez důkazu tato dvě tvrzení zaměnil. I v případě Hitlera byla drtivá většina lidí, kterých se jeho činy dotýkaly, proti. V demokratické společnosti platí názor většiny, a pokud je většina pro změny, nic s tím nezmůžete. Je to blbej systém, ale ty ostatní jsou jenom horší. Ano? Zkuste si vzít obrovský prostor zvaný Německo a zkuste si zjistit jak moc lidí bylo proti. Demokracii sem netahejte - navíc znovu - dokažte tvrzení že všechny ostatní systémy jsou horší, než demokracie - měl byste logický problém. Miloslav Ponkrác ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
