[python] Buducnost Pythonu: lambda, map, filter

Roman Miklos RMiklos na pss.sk
Pátek Listopad 10 14:48:22 CET 2006


>superman:

>a = 2
>if a:
>   print "je to tam"
>Já bych si přál jazyk, který striktně přikazuje napsat:
>a = 2
>if a != 0:
>   print "je to tam"

Je zjavne ze toto Python prebral z Perlu, ked vznikal snazil sa vela 
prebrat z Perlu. Tam sa tiez vsetko > 0 vyhodnocuje ako True a to umoznuje 
pisat tie typicke veci ako
open(IN, "program.log")
    or die "Nejde otvorit subor\n"; 

Ja osobne si myslim, ze toto uzitocne pre skriptovaci jazyk

>Jde o hrubé PORUŠENÍ ZPĚTNÉ KOMPATIBILITY jazyka, a pokud vím, zatím 
žádný 
>jazyk tohle nepřežil ve zdraví.

To si myslim tiez :-) 
Pamatam si (kedysi som robil numeriku aj vo Fortrane 77) ked som videl 
Fortran 90/95 tak ma to totalne rozculilo  preco sa to stale vola Fortran, 
ked je to uplne ine...Neviem jak to tam teraz vyzera, ale myslim si, ze 
zlomok tych ktori robia vo Fortrane 90/95 je mizivy proti tym co robia 
nadalej v g77.

>..nemá Python vůbec nárok tyto věci z jazyka vyhazovat.

Toto si myslim tiez, lebo Python mi je jediny znamy jazyk, ktory podporuje 
3 paradigmy:
proceduralny
funkcionalny 
objektovo orientovany

A vsetky tieto 3 paradigmy su v Pythone v uplnej harmonii a mozes sa 
slobodne rozhodnut ako ich vzajomne sklbis. 
FP je tu prave urobene nenasilnou formou, neutopis sa v mnozstve zatvoriek 
ako v Scheme/LISP a jazyk je pekny (nie ako Haskell) 
Argumenty typu, co je efektivne, alebo neefektivne (ze napriklad map() je 
menej efektivny ako urobit to cez cyklus) si myslim, ze sa do tohoto 
jazyka nehodia, pretoze je to jazyk skriptovaci. /Kto chce robit efektivny 
pristup do databazy nech to robi cez nativne pristupy (COBOL, RPG) a kto 
chce robit rychle systemove veci nech si zvoli C++./
Okrem toho sa kazdy v Pythone moze rozhodnut pouzit iny pristup a nie FP.

Myslim, ze jednym z hlavnych cielov Pythonu bolo aby bol kod kompaktny a 
zrozumitelny, preto zaviedli aj povinne odsadzovanie, ktore mi na Pythone 
zo zaciatku vadilo, ale postupom casu som uznal ze to fakt kod 
standardizuje a robi ho zrozumitelnym. 
Jednou z veci ako urobit kod kompaktnejsim a na niektorych miestach aj 
zrozumitelnejsim boli prave aj prvky FP. A preto ma Guido dost prekvapil, 
ked to chce odstranit. 

Dufam, ze nejakym sposobom sa FP v Pythone zachova, bud budu k tomu 
vytvorene nejake moduly, alebo mozno vznikne iny jazyk zalozeny na Pythone 
2.x, ktoreho verzie mozu napr. konvergovat k e = 2.7182.... 
 

Mgr. Ing. Roman MIKLÓŠ 
Prvá stavebná sporiteľňa a.s. 
Bajkalská 30, P. O. Box 48 
829 48  Bratislava 25 
Tel.: +421/ 2 / 582 31 174 
Fax: +421/ 2 / 582 31 109 



Další informace o konferenci Python