Re: [python] MySQL - nativní rozhraní pro Python

2008-06-30 Tema obsahu zu1234
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

2008-06-30 Tema obsahu zu1234
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

2008-06-30 Tema obsahu Tomas Brabenec
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

2008-06-30 Tema obsahu superman
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

2008-06-30 Tema obsahu zu1234
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-06-30 Tema obsahu Jan Bednařík
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

2008-06-30 Tema obsahu zu1234
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

2008-06-30 Tema obsahu Jirka Vejrazka
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-06-30 Tema obsahu Jan Bednařík
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

2008-06-30 Tema obsahu Jan Bednařík
 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

2008-06-30 Tema obsahu superman

 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