Python a vůbec (diskuse)

[Kníže Ignor]

Wow, to mi připomnělo Haskell. Python je funkcionální jazyk? Nebo kam ho zaškatulkovat?

[Mikos]

V Pythonu je možno programovat objektově, funkcionálně i procedurálně. A od doby co jsou v něm dekorátory snad i aspektově (ale to jen tlumočím co jsem si někde přečetl, ve skutečnosti nemam zdání co to aspektové programování je ).

[JiK]

muzete me, polodebilnimu chemikovi, ktery 'programuje' akorat v bashi a maturoval s pascalu/gwbasicu v DOSu, vysvetlit co ze je to "objektově, funkcionálně, procedurálně a aspektově" ???

Co je to objektove orientovane programovani? Jak bys to vysvetlil sve babicce? Upozornuju, ze s kazdou ucebnici ANSI C jsem skoncil tak na strane 6-8 kdy zacli mluvit o pointerech a tak. proste mi to hlava nebere. Ja doted nejsem chopen pochopit, jak, kdyz se progam vykonava po radkach, (asi i binarka pak nejak odpovida tem puvodnim radkum) se muzou dit 2 nebo vic veci "naraz" proste si neumim predstavit, jak to funguje uvnitr, jak se mohou naraz pocitat v jednom bezicim programu 2 a vice uloh, rekneme trebas pocitat 2 faktorialy naraz, nebo v nejake hre vykreslovat grafiku a zaroven pocitat AI protivniku....

[Hynek (Pichi) Vychodil]

Co je to objektove orientovane programovani? Jak bys to vysvetlil sve babicce?

Objektově orientované programovaní používá objekty. Objektem je souhrn vlastností a věcí co s ním lze dělat. Například míč může být objekt, ten má třeba barvu a jde ho nakopnout. No a tomu samotnému pojmenování míč, tomu říkáme třída objektů, protože ve skutečnosti, když se řekne míč, tak tím nemyslíme konkrétní míč, ale všechny míče. Pak kdyše řekne tento míč, tak máme na mysli konkrétní míč s jeho aktuální barvou, třeba červenou a když ho nakopneme, tak poletí určitou rychlostí, protože kromě barvy měl třeba konkrétní hmotnost atd. Krom toho mezi míči máme další podskupiny, jako baskedbalový míč, fotbalový míč atd. Těmto třídám říkáme dědičné třídy od třídy míč, protože po třídě míč dědí některé vlastnosti, třeba že jsou kulaté. No a objektově orientované programování na všechno kouká jako na objekty. Tak to by bylo pro babičku a pro tebe bych k tomu dodal, že těm vlastnostem říkáme atributy a jsou to vlastně data. To co s nima jde dělat říkáme metody a tím, že voláme metody nad určitým balíkem dat dosáhneme jejich zapozdření a tomu dohromady říkáme objekt. V určitých případech to zjednodušuje a zpřehedňuje programování. Krom toho bych babičku i tebe odkázal na nějakou učebnici OOP

Upozornuju, ze s kazdou ucebnici ANSI C jsem skoncil tak na strane 6-8 kdy zacli mluvit o pointerech a tak. proste mi to hlava nebere. Ja doted nejsem chopen pochopit, jak, kdyz se progam vykonava po radkach, (asi i binarka pak nejak odpovida tem puvodnim radkum) se muzou dit 2 nebo vic veci "naraz" proste si neumim predstavit, jak to funguje uvnitr, jak se mohou naraz pocitat v jednom bezicim programu 2 a vice uloh, rekneme trebas pocitat 2 faktorialy naraz, nebo v nejake hre vykreslovat grafiku a zaroven pocitat AI protivniku....

Tak tohle s tím moc nesouvisí, jinak ten kód se skutečně vykonává na jednom procesoru postupně, to zaráz se dosahuje trikem, třeba, že každý chvilku tahá pilku, nebo se tam těch procesorů strčí víc

[Petr Bayer]

A nebo jinak. Mame tridu, ta je sablonou pro vytvareni predmetu. Tyto predmety nazyvame objekty. Takze mame treba tridu (sablonu) mic a ted si podle ni udelame objekt (predmet), alias instanci tridy. Nazveme ho treba petruv_mic. A tomuto objektu pak muzeme posilat zpravy, aby nam treba "rekl" jake je barvy, a nebo aby letel urcitym smerem, atd. To je objektove programovani. Pak jsou tam jeste jine veci jako je dedicnost (kdy vytvarime novou tridu tim, ze "zkopirujeme" a upravime jinou tridu (treba z obecneho mice udelame rugbyovy_mic, fotbalovy_mic apod.)) atd.

[msk]

Skusim to na jednoduchom priklade:

funkcionalne:
Auto a;
Auto b;
chod_do_lava ( a );
chod_rovno ( a );
pockaj_na_druhe_auto ( a, b );
print zisti_rychlost_auta ( b );

objektovo ( metody su priamo sucast auta ):
Auto a;
Auto b;
a.dolava();
a.rovno();
a.pockaj_na ( b );
print b.rychlost();

Samozrejme to ma vyhody uplne inde, ako len syntakticky zapis, ale ako priklad to snad pomoze.

[Mikos]

Nemůžu si pomoct, ale přijde mi, že sis spletl funkcionální programování s procedurálním

[Martin]

Taky mám ten pocit :o)

V procedurálním programování se používají funkce, ale to je tak všechno :o) To má s funkcionálním programováním společnýho akorát kousek názvu.

[Hynek (Pichi) Vychodil]

Hmm, funkcionálně asi takhle:

rychlost(cekalo_se_na_nej(auto('b'), jelo_rovne(zahlo_doleva(auto('a'))))

[Messa]

Jaký je rozdíl mezi funkcionálním a procedurálním programováním? Vzpomínám si jen, že v Pascalu byly procedury a funkce a pro mě jediný rozdíl byl v tom, že procedury nevracely návratovou hodnotu, tedy pokud si dobře pamatuji…

[Michal Vyskočil]

Což ovšem funkcionální programování určitě není. I proto, že Pascal se inspiroval Algolem a rozlišuje přiřazení a výrazy .

Pokud už funkcionální programování, tak Lisp, nebo raději Haskel.

[Radek Šlesinger]

Snad nebudu moc mystifikovat. Výpočet v imperativním jazyce znamená postupné vykonávání příkazů, jak jdou za sebou, mezivýsledky si ukládáš do proměnných, můžeš používat cykly.

Pascal:

function SumOneToN (n : Integer) : Integer;
var i,s : Integer;
begin
  s := 0;
  for i := 1 to n do
    s := s + i;
  SumOneToN := s
end;

Ve funkcionálním jazyce je to postupné zjednodušování nějakého výrazu, nejsou k dispozici proměnné, místo cyklů je rekurze.

Haskell:

sumOneToN :: Int -> Int
sumOneToN n = if (n <= 0) then 0
                          else (n + (sumOneToN (n-1)))

Dále, ve funkcionálních jazycích jsou funkce "first class citizens", tj. můžou být předávány jiným funkcím jako parametry a také vraceny jako výstupní hodnoty. Třeba zde značí . operátor, který vezme 2 funkce a vrátí jejich kompozici (pokud je to typově možné).

sumOneToSqrN :: Int -> Int
sumOneToSqrN = sumOneToN . (\n -> n*n)

No prostě jsou to samé pěkné věci.

[Michal Vyskočil]

Dále, ve funkcionálních jazycích jsou funkce "first class citizens", tj. můžou být předávány jiným funkcím jako parametry a také vraceny jako výstupní hodnoty. Třeba zde značí . operátor, který vezme 2 funkce a vrátí jejich kompozici (pokud je to typově možné).

To znamená, že ukazatele v C umožňují funkvionální programování i v něm?

[Radek Šlesinger]

To jsou mi teda věci, to abych se na ten jazyk podíval.

[Hynek (Pichi) Vychodil]

Vždyť je to úplně přirozené, když jde v C naprogramovat haskell, tak proč by nemělo jít funkcionálně programovat v C? Jen ten zápis je takový ... ehm. V jakémkoli jazyce s vyjadřovací schopností Turingova stroje lze použít jakékoliv programovací paradigma, které lze na takovém stroji realizoavt, že?

[Michal Vyskočil]

Nechci schladit tvoje nadšení, ale funkcionální programování v Pythonu je až něco navíc ... neříkám, že to nejde, ale není to ono. Primárně je to oop jazyk, který ovšem umožňuje používat i procedurální paradigma (což je něco, co nenávidím na Javě, která to tak jednoduše neumožňuje).

[VícNežNic]

public class neco {
  public static void main (String args []) {
    //tady jsou procedurální draci 
  }
}

A je to, ne? (dělám si pochopitelně srandu )

[Michal Vyskočil]

Přesně tak, ten syntaktický cukr v Javě poměrně často zhořkne

[Hynek (Pichi) Vychodil]

map(lambda x:x*2, a)

nahradím

[x*2 for x in a]

nebo

filter(lambda x:x%2, a)

nahradím

[x for x in a if x%2]

ale co třeba

a={'a':1, 'b':3, 'c':2}
[ key for key, value in sorted(a.iteritems(), key=lambda x:x[1])]

to se dá nahradit kostrbatým

def getValueFromPair(x): return x[1]
[ key for key, value in sorted(a.iteritems(), key=getValueFromPair)]
del getValueFromPair

ale proč to dělat jednoduše, když to jde složitě, že. Jen podotýkám, že

[ key for value, key in sorted((value, key) for key, value in a.iteritems())]

není totéž, i když skoro.

[Hynek (Pichi) Vychodil]

mezi definicí té funkce a použitím musí být volný řádek. Někde se mi to stratilo.

[Jan Martinek]

Myslím, že jsme se o tom tudlevá bavili. Jde tedy o to, že mám slovník a chci získat jeho klíč i hodnotu setřídené podle hodnoty, že? Možnosti jsou v principu dvě:
1) Získat klíče a ty si schovat do nového listu(což vezme nějakou paměť). Tyto klíče setřídit podle hodnoty, přičemž během třídení je nutno vždy vyhledávat ve slovníku příslušnou hodnotu. Pak sekvenčně procházet setříděné klíče a opět vyhledávat příslušnou hodnotu.

2) Zkonvertovat slovník na seznam, kde klíč a hodnota budou vždy nějak pospolu. To sežere (na okamžik) víc paměti než v přechozím případě. Pak tento seznam setřídit. Pak ho procházet sekvenčně a získávat (bez vyhledávání) klíč i hodnotu.

První způsob lze napsat třeba takto:

keys = d.keys()
keys.sort(key = d.__getitem__)
for key in keys:
    res = key, d[key]

Zatímco druhý způsob (který jsi tehdy nazval opičárnou)

pairs = [(v, k) for (k, v) in d.iteritems()]
pairs.sort()
for v, k in pairs:
    res = k, v

První způsob je dvakrát rychlejší (což mě celkem překvapuje) a bere míň paměti. Ale zase se mi tam moc nelíbí to __getitem__.
Těžko říct, co je čitelnější a co je ona jediná Správná Cesta. Ale oba způsoby jdou napsat bez lambdy.

[Jan Martinek]

První způsob lze ještě přepsat na

for key in sorted(d.keys(), key= d.__getitem__):
  res = key, d[key]

(netvrdím, že je to lepší). S tím druhým (alias opičárnou) se mi nic vymyslet nepodařilo.

[Hynek (Pichi) Vychodil]

Jenže tady je právě zakopanej pes a dost páchne.

ad 1) Co když d vlastně neexistuje, ale je to třeba dict(<generátor>). To se pak jde funkcionální programování klouzat, protože to nejde udělat bez explicitního uložení toho seznamu.

ad 2) Tak to právě dělá ten poslední příklad na který upozorňuji, že nedělá totéž, zkus si to třeba na na dict((x, len(x)) for x in ('a', 'b', 'c', 'd', 'e')), Vtip je v tom, že nechci řadit podle (hodnota, klic), ale jen podle hodnoty ať už z jakéhokoli obskurního důvodu.

A proč je to první méně náročné na paměť? No tak to bych si typnul, že to bude tím, že uložení listu skalárů zabare míň místa, než uložení listu tuple. A proč je to rychlejší, no tak za to může zase betálně rychlé vyhledávání v dict. Si pamatuju jak jsem byl překvapený jak je to rychlé v perlu.

[Jan Martinek]

Jenže tady je právě zakopanej pes a dost páchne. ad 1) Co když d vlastně neexistuje, ale je to třeba dict(<generátor>). To se pak jde funkcionální programování klouzat, protože to nejde udělat bez explicitního uložení toho seznamu.

To si nějak neumím představit, ale asi máš recht. IMHO bez předchozího uložení je slovník trochu k ničemu, ale třeba jsou výjimky ...

ad 2) Tak to právě dělá ten poslední příklad na který upozorňuji, že nedělá totéž, zkus si to třeba na na dict((x, len(x)) for x in ('a', 'b', 'c', 'd', 'e')), Vtip je v tom, že nechci řadit podle (hodnota, klic), ale jen podle hodnoty ať už z jakéhokoli obskurního důvodu.

Jo, aha.
Tak jsem dal dohromady všechny dosavadní poznatky a dospěl k tomuhle řešení

def getValueFromPair(x): return x[1]

items = d.items()
items.sort(key = getValueFromPair)
for k, v in items:
    res = k, v

Zjišťoval jsem, jak dlouho se vyhodnocují různé varianty a tohle je druhé nejrychlejší (asi o 30% pomalejší než key=d.__getitem__). Je to asi ta nejkostrbatější možnost, ale mě se líbí. Ale já jsem byl vždycky divnej. Dal by se ušetřit řádek, kdybych použil sorted(), ale žere to paměť a byla by škoda zbytečně zahodit ten setříděný seznam.

[Hynek (Pichi) Vychodil]

Dal by se ušetřit řádek, kdybych použil sorted(), ale žere to paměť a byla by škoda zbytečně zahodit ten setříděný seznam.

Právě že sorted žádnou paměť navíc nežere, ale musí se použít iterátor, tedy ne items, ale iteritems, případně iterkeys.

[Jan Martinek]

Měl jsem na mysli sorted() versus sort(). Sort je k paměti šetrnější, protože nemusí vytvářet kopii seznamu -- a doufám, že to nedělá. Mění ten seznam přímo. Zatímco sorted vrací setříděnou kopii a původní pole nechá beze změny.:

>>> import random
>>> a = range(10)
>>> random.shuffle(a)
>>> b = sorted(a)
>>> a
[3, 2, 1, 5, 7, 8, 0, 4, 6, 9]
>>> b
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> a.sort()
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

[Hynek (Pichi) Vychodil]

Ano o tom není sporu, že použít sorted na již hotový list je hloupost, já jen tvrdím, že mezi zápisem

a = [<iterátor>]
a.sort()

a zápisem

a = sorted(<iterátor>)

není žádný rozdíl co do spotřeby paměti viz. např.

a = file('<filename>','r').readlines()
a.sort()

a

a = sorted(file('<filename>','r'))

[Jan Martinek]

... já jen tvrdím, že mezi zápisem

a = [<iterátor>]
a.sort()

a zápisem

a = sorted(<iterátor>)

není žádný rozdíl co do spotřeby paměti...

To, že je to iterátor, podle mě nemá na nic vliv. Jestliže napíšu

#!/usr/bin/env python
import random

a = range(5)
random.shuffle(a)
print a

def gimme_next():
    for i in a:
        print 'Yielding: ', i
        yield i

def compare(a, b):
    print 'Comparing:', a, b
    return cmp(a,b)


b = sorted(gimme_next(), compare)
print b

Tak se
1) pomocí iterátoru se získá celý seznam
2) tento seznam se zkopíruje
3) zkopírovaný seznam se setřídí
4) původní seznam se zahodí, protože už na něj není reference

Takže v bodě 2 a 3 existují v paměti _dva_ seznamy. Bohužel, nemám pro své tvrzení žádný přímý důkaz. Snad jen to, že

items = sorted(d.iteritems(), key = getValueFromPair)

je pomalejší než

items = d.items()
items.sort(key = getValueFromPair)

[Hynek (Pichi) Vychodil]

1) pomocí iterátoru se získá celý seznam
2) tento seznam se zkopíruje
3) zkopírovaný seznam se setřídí
4) původní seznam se zahodí, protože už na něj není reference

A pro toto tvrzení v bodě 2) máte nějaký důkaz, nebo jste si to jen tak typnul? No jasně že ne: Bohužel, nemám pro své tvrzení žádný přímý důkaz. Jestli se to tak děje, tak by se autor implementace sorted měl pověsit za koule do průvanu. Není totiž nejmenší důvod to implementovat jinak, než prostě nekopírovat a jednoduše použít ten seznam získaný v bodě 1). Experimentálně se mi zdá, že je tam drobný rozdíl v rychlosti, ale ten je rozhodně menší než co mi vzniklo, když jsem jsem tu kopii udělal schválně. Rzdíl mezi sorted a .sort mi vyšel 4.4% a mezi .sort a .sort s kopií navíc je 11.2% tedu více než dvojnásobný.

d=dict((x, random.randint(0,100)) for x in xrange(100))

def useSorted():
    a = sorted(d.iterkeys(), key=d.__getitem__)

def useSort():
    a = d.keys()

def useSortAndCopy():
    a = d.keys()
    a.sort(d.__getitem__)
    b = a[:]

Jediný důvod co mě napadá je ten, že a = d.keys() je rychlejší než a = [x for x in d.iterkeys()]. Funkce sorted může být (bez reversed) klidně implementována takto:

def sorted(seq, **argv):
    a = [x for x in seq]
    a.sort(**argv)
    return a

Ve skutečnosti jsou tam ještě nějaké opičky s reversed, ošetření vstupních parametrů a ještě ke všemu implementace možná v C.

[Jan Martinek]

Funkce sorted může být (bez reversed) klidně implementována takto:

def sorted(seq, **argv):
    a = [x for x in seq]
    a.sort(**argv)
    return a

Máš recht. No jasně. To jsem sám rád, že se ten seznam neduplikuje.

[Kyosuke]

Bez ohledu na rychlost mi zatím funguje tohle:

d.sort_by{|x| x[1]}.map{|x| x[0]}

Radši to nebudu benchmarkovat, sort_by se slovníkem dělá pěkné neplechy...

[Mikos]

Můžu se zeptat proč do diskuze o Pythonu taháš Ruby?

[Kyosuke]

Páč jsem blbej a nic jinýho neumím? Ne, mně spíš překvapuje, že ani jedno z těch pythonovských řešení mi nepřijde nijak supersrozumitelné. Myslel jsem, že na tohle bude v Pythonu přímo nějaký idiom.

[Mikos]

Pokud se budu držet původního zadání, tak:

In [14]: [k for k in sorted(a.keys(), key=a.__getitem__)]
Out[14]: ['a', 'c', 'b']

Což mi přijde srozumitelné dostatečně

[Hynek (Pichi) Vychodil]

No já jsem puntičkář, takže

[k for k in sorted(a.iterkeys(), key=a.__getitem__)]

ale to je detail Jinak to má ale ten zádrhel, že si to neporadí s ad hoc generovaným dict, nebo vráceným třeba z funkce a nechci si ho někam ukládat. Když tak nad tím přemýšlím, tak mě nenapadá realný příklad, kde by to bylo potřeba Krom toho ve 2.5 přichází with, ale moc jsem ho nepochopil, tak nevím jestli to není zrovna lék na tohle.

[Jan Martinek]

... mně spíš překvapuje, že ani jedno z těch pythonovských řešení mi nepřijde nijak supersrozumitelné.

Záleží na tom, jak je v kdo zvyklý. A především záleží na tom, jak se to napíše. U méně přehledných částí kódu vždy pomůžou komentáře nebo alespoň vhodný název funkce, třeba sort_dict_by_value().

Myslel jsem, že na tohle bude v Pythonu přímo nějaký idiom.

Idiom pro to není. Kupodivu se tohle téma řešilo už před pěti lety v PEP 265:
http://mail.python.org/pipermail/python-dev/2001-August/017143.html
A objevilo se několik zlepšovacích návrhů. Guido van Rossum (hlavní vývojář Pythonu) všechno zamítl s tím, že to není nezbytně nutné a nestojí to za to.
V tomto případě s ním plně souhlasím. Odmítl dokonce možnost

items = d.items(values_first=0)

která by obrátila pořadí v tuplech u vytvářeného seznamu. I když je to asi dobrá myšlenka, při přidávání featur do jazyka je potřeba být _VELMI_ opatrný (musí se spravit dokumentace všude možně, zastarají knihy, přestanou platit doporučené způsoby atd.)

[Jan Martinek]

Můžu se zeptat proč do diskuze o Pythonu taháš Ruby?

Ále, však ho nechme. Sám jsem taky zaplevelil Pythonem několik diskusí o shellu. A nehodlám s tím přestat

[python2]

Lambda v pythonu zustane.

[Jan Martinek]

Je pravda, že jsem nikde nenašel konkrétní rozhodnutí, jestli tam zůstane nebo ne. Ale Guido van Rossum by se jí rád zbavil:
http://www.advogato.org/article/846.html
Vždy je možné se bez lambdy obejít a napsat jednořádkovou funkci:

def compare(a, b): return cmp(a[1], b[1])

items = d.items()

s lambdou: items.sort(lambda x,y:cmp(x[1], y[1]))
bez lambdy: items.sort(compare)

Lambda dokáže ušetřit jeden řádek kódu, ale v Pythonu vznikla spíš z historických důvodů, aby Python někdo nepomluvil, že není dost funkcionální.
Rád bych podotkl, že zápis s lambdou je sice stručnější, ale lambda je pomalejší než jednořádková funkce.

[Jan Martinek]

Aha, už jsem to našel:
http://mail.python.org/pipermail/python-dev/2006-February/060415.html
Takže máte pravdu -- lambda v Pythonu zůstane. Víceméně proto, aby ustaly hádky o jiném řešení.

[Hynek (Pichi) Vychodil]

Rád bych podotkl, že zápis s lambdou je sice stručnější, ale lambda je pomalejší než jednořádková funkce.

Tak když jsem tohle četl, tak jsem tomu nemohl uvěřit a je to blbost nebo je rozdíl menší než 1%. To by bylo teda pěkně pitomě implementováno. Krom toho přímo v dokumentaci říkají, že lambda je jen zkratka pro takovou jednořádkovou funkci.

import os, itertools, random

d=dict((x, random.randint(0,100)) for x in xrange(10000))

def timeItDet(func, n=1000):
     start = os.times()
     for x in itertools.repeat(None, n):
         func()
     return tuple(x-y for x, y in itertools.izip(os.times(), start))

def doItSmart():
    sortedKeysByValues = sorted(d.iterkeys(), key=d.__getitem__)

def withLambda():
    items = d.items()
    items.sort(lambda x, y: cmp(x[1], y[1]))

def withoutLambda():
    def cmpValues(a, b): return cmp(a[1],b[1])
    items = d.items()
    items.sort(cmpValues)

timeItDet(doItSmart,100)
(2.1699999999999875, 0.020000000000000018, 0.0, 0.0, 2.1899999999995998)

timeItDet(withLambda,100)
(15.830000000000013, 0.040000000000000036, 0.0, 0.0, 15.859999999999673)

timeItDet(withoutLambda,100)
(15.829999999999984, 0.010000000000000009, 0.0, 0.0, 15.840000000000146)

Měřil jsem to víckrát a ten rozdíl je na hranici měřitelnosti.

[Jan Martinek]

U mě ten rozdíl dělá něco přes dvě procenta. Celkem reprodukovatelně. Je mi to taky divný. Ještě se na to podívám. Ale pro jistotu tedy změním svoje tvrzení - lambda není rychlejší.

[Hynek (Pichi) Vychodil]

Použil jste stejnou metodologii? On je rozdíl mezi:

def f(): return <expression>
<mesure start>
<repeat>: test(f)
<mesure stop>

<mesure start>
<repeat>: test(lambda: <expression>)
<mesure stop>

a

<mesure start>
<repeat>:
    def f(): return <expression>
    test(f)
<mesure stop>

<mesure start>
<repeat>: test(lambda: <expression>)
<mesure stop>

V tom prvním případě musí lambda samozřejmě prohrát

[Jan Martinek]

V tom by mohlo být jádro pudla. Ale nepoužívám opakované třídění. Třídím pouze jednou, ale zato velký seznam, takže lambda je trochu v nevýhodě.

[Hynek (Pichi) Vychodil]

Čím je ten seznam delší, tím v menší nevýhodě by měla ta lambda být. To bude asi ještě v něčem jiném.

[Tom.š Ze.le.in]

Vždy je možné se bez lambdy obejít a napsat jednořádkovou funkci

- v Python nejsou funkce vracející funkce (nově vytvořené na základě parametrů)? To mi přijde jako ten případ, kdy se lambda za pojmenovanou funkci nahradit nedá...

[Jan Martinek]

Měl jste na mysli něco takového?

#!/usr/bin/env python
def nova_funkce(param):
    def odecti(a, b):
        return a - b
    def pricti(a, b):
        return a + b
    if param == 'odecti':
        retvalue = odecti
    elif param == 'pricti':
        retvalue = pricti
    else:
        raise SystemExit, "Spatny nazev funkce"
    return retvalue

f = nova_funkce('odecti')
print f(5, 3)
f = nova_funkce('pricti')
print f(5, 3)

Nebo jde o něco složitějšího?

[Tom.š Ze.le.in]

Půjde takhle bez lambdy i tohle? (nemám po ruce python, jinak bych vyzkoušel sám)

def pricti_n(n):
    def pricti(a):
        return a + n
    return pricti

f = pricti_n(3)
print f(5) => 8

[Jan Martinek]

Dal jsem to do Pythonu a vyhodilo to osmičku. Tak to asi funguje.

[Tom.š Ze.le.in]

Aha, tak to si zlepšuju názor na Python. Proč jsem si myslel, že v tom je problém? :)

Asi zagooglím python closures...

[Hynek (Pichi) Vychodil]

Z funkce lze vrátit libovolný objekt, tedy i funkci alébržto funkce je taky objekt