Re: [python] PyFormat 0.1.0 released
Dne pondělí 22. srpna 2016 23:43:41 UTC+2 Pavel Schön napsal(a): > > Je super vidět boost::python v praxi. > To jsem rád. > > > Jen instalace by možná byla lepší pomocí setup.py a trochu obecnější, než > > Debian balíček. Byly s tím setup.py nějaké problémy, nebo je to v todo > > listu, nebo se to zatím nezkoušelo? :) > > setup.py se zkoušelo také, ale je problém s detekcí libboost_python. (každá > distribuce to má jinde a jinak pojmenované (debian: libboost_python-py27.so > resp. libboost_python-py34.so ) > > make install by měl také fungovat. > > Co se týče balíčků, tak CMake umí generovat i rpm, ale nemám to jak > otestovat, tak jsem to tam radši nedal. Klidně pošli pull request pro rpm i > setup.py :) S tvorbou RPM balíčku rád pomůžu. Je už nějak připraven a je ho třeba jen otestovat? > > > >>> fmt1, fmt2 = U('first'), U('second') > > > > >>> fmt1.swap(fmt2) > > > > swap operátor v Pythonu? Interjazyková prasárna :) > > > > haha, ale tady je to myšlěno zcela vážně :) Dovedu si představit využití > třeba s coroutinami... ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] PyFormat 0.1.0 released
> Je super vidět boost::python v praxi. To jsem rád. > Jen instalace by možná byla lepší pomocí setup.py a trochu obecnější, než > Debian balíček. Byly s tím setup.py nějaké problémy, nebo je to v todo listu, > nebo se to zatím nezkoušelo? :) setup.py se zkoušelo také, ale je problém s detekcí libboost_python. (každá distribuce to má jinde a jinak pojmenované (debian: libboost_python-py27.so resp. libboost_python-py34.so ) make install by měl také fungovat. Co se týče balíčků, tak CMake umí generovat i rpm, ale nemám to jak otestovat, tak jsem to tam radši nedal. Klidně pošli pull request pro rpm i setup.py :) > >>> fmt1, fmt2 = U('first'), U('second') > > >>> fmt1.swap(fmt2) > > swap operátor v Pythonu? Interjazyková prasárna :) > haha, ale tady je to myšlěno zcela vážně :) Dovedu si představit využití třeba s coroutinami... ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] PyFormat 0.1.0 released
Je super vidět boost::python v praxi. Jen instalace by možná byla lepší pomocí setup.py a trochu obecnější, než Debian balíček. Byly s tím setup.py nějaké problémy, nebo je to v todo listu, nebo se to zatím nezkoušelo? :) >>> fmt1, fmt2 = U('first'), U('second') > >>> fmt1.swap(fmt2) > swap operátor v Pythonu? Interjazyková prasárna :) Mimochodem, když už jsme u toho formátování, pro někoho, kdo to třeba ještě neví, tak aby se mohl těšit - v Pythonu 3.6 je možné formátovat ještě jednodušeji: a, b, c = 1, 2, 3 print(f"{a} {b} {c]") # vypíše "1 2 3" PM ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
[python] PyFormat 0.1.0 released
Zdravím, chtěl bych zde uvést nový projekt "PyFormat", který zpřístupňuje třídu boost::format z balíku C++ knihoven Boost.org. Pokud někdo používáte Boost, jistě znáte i boost::format. Modul PyFormat funguje pro Python 2.x a 3.x a podporuje byte stringy i unicode stringy. Mezi killer feature patří fakt, že formátovací string je syntakticky validován a zkompilován během inicializace a ne až při vyhodnocení, kdy už může být pozdě. Dále je třeba zmínit, že format objekt lze hodnotami plnit postupně a ne nutně najednou. (operátor % vrací self) Pomocí bitmasky lze konfigurovat, které chyby budou raisnuty a které ignorovány (např. nesprávný počet argumentů). Nevýhoda je, že boost::format je relativně pomalý, takže se nedivte, pokud budou výsledky horší než u nativního formátování v pythonu. Ale cíl projektu není překonat nativní formátování co do rychlosti, ale co do features a robustnosti a poskytnout kompatibilní vrstvu pro další projekt, který má boost::format na vstupu-ale o tom zas jindy. Třídy v modulu: Format: bytestringy, Python2: __str__, Python3: __bytes__ UFormat: unicode stringy, Python2: __unicode__, Python3: __str__ Základy použití modulu: --- >>> from pyformat import Format as F, UFormat as U >>> fmt = U('%s %s %s') >>> print(fmt % 'a' % 'b' % 'c') a b c >>> print(fmt % 1 % 2 % 3) 1 2 3 Klonování: --- from pyformat import Format as F, UFormat as U tmpl = U('foo %s') # parsed only once def foo(i): fmt = tmpl.clone() # clone parsed object (copy.copy() also works) print(fmt % i) foo(1) foo(2) foo(3) Prohození: - >>> fmt1, fmt2 = U('first'), U('second') >>> fmt1.swap(fmt2) Projekt včetně popisu dalších featur je ke stažení na https://github.com/pavelschon/PyFormat Budu rád za každý bug report a pull request. ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Nej*ne*oblíbenější modul
Konkrétne napr flask-security. Má tri major ORMka a ak si pozrieš dokumentáciu, očakáva že použiješ špecifické classy práve z jedného z nich. Nieje to závisloť libky na inej libke, je to vnucovanie konkrétneho frameworku a prístupu userovi onej libky. Nieje to o tom že flask-security závisí na SQLAlchemy a ty to proste nainštaluješ ako závislosť. Už si povinný používať objekty a do svojho programu zapracovávať SQLAlchemy (alebo ich monkey patchovať). Pre porovnanie Flask-Login požaduje clasu pre Usera, ktorá implementuje nejaké API. Thats all. Naprgaš to v SQLAlchemy? Inom ORM? ako C modul? Libke je to jedno. On 22.08.2016 17:17, Pavel Schön wrote: Dne středa 17. srpna 2016 13:12:13 UTC+2 Ken Mijime napsal(a): Osobne prestávam mať rád libky, ktoré po mne požadujú konkrétny prístup. Najviac je to asi vidieť na všemožných nástrojoch, ktoré ticho predpokladajú že použijete SQLAlchemy a priam to vynucujú. A pritom dependency injection nieje taký hack ako to znie.. Zrovna na tomto mi nepřijde nic divného, že knihovna B závisí na knihovně A, podle mě úplně normální věc. Uvedl bys nějaký příklad, kde závislost B na A je nežádoucí nebo zbytečná? Např. s SQLAlchemy když už to tu padlo. ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Nej*ne*oblíbenější modul
Zdravím V Wed, 17 Aug 2016 01:34:39 -0700 (PDT) Pavel Schön napsáno: > Zdravím, zajímalo by mě, jaký je váš nej*ne*oblíbenější modul, resp. > balíček v pythonu, zejména ze standartní knihovny. Napište také, proč > tomu tak je. Co se dokumentace týče, už jsem to tu psal. Čas od času prostě potřebuji víc, než je v dokumentaci. A to z různých důvodů. Buď dokumentaci nepochopím, nebo to tam prostě napsané není. Osobně jsem se hodně kroutil u cgi modulu. Ten se dnes již ale moc nepoužívá, takže to je trochu mimo mísu. Jinak po vzoru tady zmiňovaného Seznamáckého obalu nad MySQL jsem si udělal vlastní obal nad MySQL a SQLite a to zejména kvůli logování a automatickému rollbacku. Tedy často jen lehké doplnění. Obecně ale musím říct, že se s pokorou snažím používat zejména standardní knihovny. A to jednak kvůli rozumnému počtu dalších závislostí a pak proto, že jedině používáním standardních knihoven Python opravdu do hloubky poznám. -- Ondřej Tůma www: http://ipv6.mcbig.cz jabber: mc...@jabber.cz twitter: mcbig_cz pgpxqsUg4mnu8.pgp Description: OpenPGP digital signature ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Nej*ne*oblíbenější modul
Dne středa 17. srpna 2016 13:12:13 UTC+2 Ken Mijime napsal(a): > Osobne prestávam mať rád libky, ktoré po mne požadujú konkrétny prístup. > Najviac je to asi vidieť na všemožných nástrojoch, > ktoré ticho predpokladajú že použijete SQLAlchemy a priam to vynucujú. > A pritom dependency injection nieje taký hack ako to znie.. Zrovna na tomto mi nepřijde nic divného, že knihovna B závisí na knihovně A, podle mě úplně normální věc. Uvedl bys nějaký příklad, kde závislost B na A je nežádoucí nebo zbytečná? Např. s SQLAlchemy když už to tu padlo. ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Nej*ne*oblíbenější modul
Hoj, V Wed, 17 Aug 2016 21:58:35 +0200 Radek Holý napsáno: > Jinak z knihoven třetích stran mě naposledy asi nejvíc vadil > PyGObject, hlavně asi kvůli tomuhle komentáři: > https://bugzilla.gnome.org/show_bug.cgi?id=571834#c1 Tahle situace je už jiná. Resp. osobně považuji GObject/GLib/GTK dokumentaci za jednu z nejlepších. PyGTK je takové partizánské, ale nové PyGObject je díky gobject-introspection velmi dobře použitelné. Vlastně Pokud něco není v dokumentaci k pythonu, tak k C určitě je, a vlastně se to dá použít, to trochu platilo i o PyGTK. S některými manýry lidí okolo GTK je to ale horší... -- Ondřej Tůma www: http://ipv6.mcbig.cz jabber: mc...@jabber.cz twitter: mcbig_cz pgpBApp0tFyDN.pgp Description: OpenPGP digital signature ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz