Statické premenné v Pythone

30.4.2009 22:35 | Přečteno: 1398× | poslední úprava: 1.5.2009 09:42

Python je fajn. update: Až doteraz... :) Ešte stále! :)

Začnem rovno kódom... (niečo ako in medias res v programovaní)

Kód:

#!/usr/bin/python
# -*- coding: utf-8 -*-

class class1():
  foo = []
  bar = ''

  def addBar(self):
    self.foo.append('bar')

  def printFoo(self):
    print self.foo

  def changeBar(self):
    self.bar = 'hello'

  def printBar(self):
    print self.bar

class class2(class1):
    pass

if __name__ == '__main__':
  c1 = class1()
  c1.addBar()
  c1.printFoo()

  c1.printBar()
  c1.changeBar()
  c1.printBar()

  c2 = class2()
  c2.printFoo()
  c2.printBar()

Vysvetlenie kódu:

foo (list) aj bar (string) sú prázdne statické premenné v class1. class2 je potomok class1.

Vytvorím inštanciu class1 s menom c1, pridám do statickej premennej foo další prvok, vypíšem.

Vypíšem statickú premennú bar, zmením jej hodnotu a opäť ju vypíšem.

Vytvorím inštanciu triedy class2 s menom c2, vypíšem statické premenné foo a aj bar.

Keďže sa jedná o statické premenné, ich zmena by sa mala prejaviť v oboch inštanciách c1 a c2, avšak nie je tomu tak. foo sa správa ako statická, t.j. c1.printFoo() a c2.printFoo() vypíšu to isté, no pri bar to tak nie je.

Na začiatku je bar prázdne, zmeníme ho, vidíme zmenenú hodnotu. Ale po vypísaní z c2 je už prázdne.

Ako je teda možné, že pri foo to funguje a pri bar nie? Je to správne správanie sa Pythonu, či som niečo opäť nepochopil?

       

Komentáře

[Honza Kral]

stringy jsou immutable, kazdym prirazenim vytvaris novou instanci, zatimco list je objekt, kde jen modifikujes vnitrni stav

[Honza Král]

jinak ani u foo by nefungovalo

self.foo = ['novy', 'list']

kdyz prirazujes na objekt, priradi se to na objekt, a prekryje to tedy ten atribut na tride.

[Milan Lajtoš]

Uuuf, ďakujem. Na mutable/immutable som vôbec nepomyslel.

Ale statické foo by sa dalo vytiahnuť cez class1.foo, aj keď by bolo prekryté atribútom na objekte. Eh, pristupovanie k statickým premenným cez inštanciu by sa malo zakázať! ;)

[CEST]

stringy jsou immutable, ..., zatimco list je objekt,

A pak me presvedcujte o tom, ze Python (a dalsi podobne jazyky ala Java, C++, vcetne meho oblibeneho Perlu) jsou objektove orientovane jazyky. Smalltalk na vas.

Pricemz me opravdu vytaci, kdyz vidim u lakadla na jazyk Python neco ve smyslu "objektově-orientovaný programovací jazyk" (viz. www.py.cz), a pak to nadherne popiraji pouzivanim prikazu (if, for, while...) nebo pouzivanim prasaren jako

re.search("c", "abcdef")

Z toho se zacatecnik akorat nauci, ze ma delat vlastni tridu, kterou bude jenom zastresovat nejaky vetsi akce, pak vytvori jenom jeden objekt tehle tridy a tam bude volat tyhle svoje metody vzdy s parametrama, misto aby vytvoril vlastni tridu, kterou vytvori rozsirenim nejaky originalni tridy a do ty pak prida vlastni metody a ty bude pak volat na ten konkretni objekt, napr. ten regular vyse by mel byt spravne

"abcdef".search("c")

Proste na objektu typu (ze tridy) string by mela byt metoda search s jednim parametrem udavajicim regexp, kterej se ma hledat v tom objektu string. Ono sice jde pomoci compile vytvorit objekt RegExp a na ten pak volat match jenom s parametrem stringu, ale bohuzel umoznuje i tu prvni prasarnu, takze se to tak zacatecnici nauci, protoze to odpovida klasickymu programovani (IMHO klasicky programovani je trosku pochopitelnejsi nez OOP).

proste v tomhle me Python znechucuje a pak jeste oddelovani prikazu odsazovanim - perl, awk, sed pouzivam v cmdline. Python mi tohle nedovoli (nebo jo?), takze s nim nemuzu zacit ani na jednoduchych vecech.

[Limoto]

>>> "string".find('t')
1
 

Ale s regexpama už to takhle nepůjde...

[jan]

Perl je multiparadigmický jazyk, ne pouze oběktový. Díky tomu je implementace oběktů, bloků atd.. jako ve smalltalku triviální, zkuste si ale ve smalltalku implementovat perl

Implementovat regexp jako obekt (a ne metodu stringu) ma take svoje vyhody - sestrojeni automatu z regexpu neni zadarmo a je dost pravdepodobne, ze jeden vyraz pouzijete vickrat nez jen jednou.

[CEST]

Perl mam rad a pouzivam ho, dokonce ho ted zacinam pouzivat misto grepu a sedu, pokud to je jednodussi, tak i awku. Objekty v perlu znam a libi se mi, ale nikdo se nesnazi presvedcovat, ze perl je skvele objektovej jazyk, zatimco u pythonu to tlaci, jak je python skvele objektovej, ze se na tom zacatecnici nauci objektove programovat. A to me stve, protoze python proste neni dobre objektovej a zaroven se michaji prikazy, funkce a metody. Smalltalk jsem uvedl, protoze jsem ho na vysokej mel a na nem je videt, co je skutecny OO jazyk.

Nejsem proti tomu, vytvorit ze stringu (zapis regexpu) objekt a na nej pak aplikovat hledani ve stringu. Jde mi o to, ze python umoznuje prasarny typu

string.match(RETEZEC,REGEXP)

protoze podle me by to melo byt spravne bud

RETEZEC.match(REGEXP)

nebo v pripade pouziti stejnyho regularu vickrat

REGEXPO.match(RETEZEC)

Proste metody, ktery pracujou s konkretnim objektem, volat primo na objekt. Ne volat metodu na tridu a nacpat ji parametry, se kteryma ma pracovat - jasne, existujou tridni metody a promenne, ktere by ale mely pracovat spis jako globalne se tridou a ne s jednotlivyma instancema. Potom si zacatecnik mysli, ze objektovy programovani je jenom o tom vytvorit tridu, do ni da vlastni funkce a pak tyhle funkce volat pres tu tridu. Proste nepochopeni OOP.

[Ondrej 'SanTiago' Zajicek]

Myslim, ze tohle je zrovna typicka ukazka nepochopeni OOP. Z hlediska OOP je uplne jedno jaky je kolem toho syntakticky cukr, zda se to vola jako match(RETEZEC,REGEXP), RETEZEC.match(REGEXP) nebo REGEXPO.match(RETEZEC). Dulezite je, kde je pozdni vazba a jak se dela dispatch podle typu. Napriklad v takovem CLOS by se to psalo match(RETEZEC, REGEXP) (nebo presneji receno (match RETEZEC REGEXP) ) a pritom je pozdni vazba a moznosti pretizeni a polymorfismu v obou argumentech.

Krom toho chapat funkci match jako metodu objektu string je IMHO dost zcestne. Ta funkce nepotrebuje zadnou interni znalost stringu krom nejakeho jeho obecneho rozhrani a nema k nemu nijak blizsi vztah nez k druhemu argumentu. V takovem pripade (kdy druhy argument je take string a ne specielni objekt typu REGEXP) je IMHO vhodnejsi pohlizet na ni jako na nezavislou funkci.

Python neznam, ale tipuji, 'string.match' je spis namespace issue, nez ze by to melo nejakou souvislost s OOP.

[joe]

"tohle je zrovna typicka ukazka nepochopeni OOP"

Presne tak, nepochopil jste podstatu spojeni "objektove orientovany".

[l4m4]

Zjevně pochopil.

Ostatně re.match(x,y) modulu re zašle zprávu match(x,y). Je to formálně úplně stejně OO jako zaslání zprávy match(y) řetězci x -- a úplně stejně z hlediska OO nedává velký smysl věcně. Nejde chtít jedno a odmítat druhé.

[Martin Mareš]

Proste metody, ktery pracujou s konkretnim objektem, volat primo na objekt.

A se kterým konkrétním objektem tato metoda pracuje? Já tam vidím konkrétní objekty dva a nedává mi smysl kterýkoliv z nich preferovat. Vaše "OO" je v tomto případě jen nepříliš logické syntaktické pozlátko (jak poznamenal již Santiago, objektovost spočívá v něčem poněkud jiném).

[JS]

 A neni to jedno? Ja treba tenhle Smalltalkovsky fundamentalismus (tj. misto len(a) musi byt a.len()) moc nechapu. Na druhou stranu, chapu Lispovy fundamentalismus - tam to ma aspon duvod (makra a genericke funkce).

[deda.jabko]

misto len(a) musi byt a.len()

tak toto povazuju za jednu z nejvetsich demenci v pythonu... (a ze by se jich jeste par naslo) ;-]

knihovny jsou napsane tak, ze nejde urcit jestli danou funkcionalitu nabizi ,,funkce'' nebo ,,metoda'' a pokud v tom clovek nedela dnes a denne tak to musi resit pokus omyl nebo dohledavani v dokumentaci.

[JS]

Hm, ja tedy ne, len(a) proste povazuji za syntakticky cukr pro volani a.__len__(), stejne jako treba a+b je syntakticky cukr pro a.__plus__(b). Nepripada mi na tom nic prilis kontroverzniho, proste len je jen jakysi dalsi operator.

Obecne nemam rad OO fundamentalisty; trochu mi pripadaji jako lide, kteri vynalezli novy zapis a domnivaji se, ze tim spasi programatorsky svet.

A naprosto souhlasim s Ondrejovym prispevkem.

[deda.jabko]

ja nejsem zadny OOP fundamentalista. me jenom vadi, ze v pripade pythonu je v tom hrozny (s prominutim) bordel. a treba v pripade toho len() me prijde logictejsi to dat jako metodu objektu, protoze se pracuje pouze s jeho vlastnostmi a nic jineho neni potreba.

[JS]

Jen pro poradek - nikdy jsem si nemyslel, ze jste OOP fundamentalista, to byla obecna poznamka. V tomto se ovsem neshodneme - me fakt, ze knihovny Pythonu nejsou vzdy plne objektove (nebo plne neobjektove) prilis nevadi (stejne musim koukat do manualu, jak se veci jmenuji a jake maji parametry, tak uz je to pak jedno).

[Michal]

U Smalltalku v tomto případě nejde o žádný fungamentalismus, je to otázka syntaxe. Ve Smalltalku se objektům posílají zprávy, žádné len(a) tedy nelze napsat (tj. klasické volání funkce), jen a len, tj. objektu a posílám zprávu len.

[l4m4]

To je syntaktický detail. Neexistuje důvod, proč by se poslání zprávy len objektu a nemohlo zapsat len(a). V Pythonu je len(x) syntaktická zkratka pro x.__len__(). Protestovat proti tomu lze z hlediska zanášení jmenného prostoru, ale ne proto, že by to nebylo OO.

[Kvakor]

Pricemz me opravdu vytaci, kdyz vidim u lakadla na jazyk Python neco ve smyslu "objektově-orientovaný programovací jazyk" (viz. www.py.cz), a pak to nadherne popiraji pouzivanim prikazu (if, for, while...)

Z toho jsem volaký zmetený. Jak se tedy mají v objektovém nefunkcionálním jazyce realizovat řídíci struktury když ne pomocí if, for a while ?

[razor]

Např jako poslání zprávy if, for, while ... objektu Boolean. http://www.friendofthepigeon.co.uk/wordpress/?page_id=45

 

[Kvakor]

Ve Smalltalku je všechno poslání zprávy, ale i v něm vypadá if i tak dost "ifózně":

'podmínka'
 ifTrue:[ 'kód vykonaný pokud splněno' ]
 ifFalse:[ 'kód vykonaný pokud nesplněno' ]

[razor]

Všechno ne. Např. příkaz "return" :)

[l4m4]

V tom případě není dost OO :o)

I mnohem úchylnější řídící konstrukce lze realizovat zasíláním zpráv objektu runtime prostředí (codestack, mašina, interpret, ...). Bude to úplně OO a Smalltalkisty přivede k orgasmu, ale to bude asi tak jediné praktické využití zapisování řídících konstrukcí tímto způsobem.

[pozortucnak]

C...gobject...gtk

[pozortucnak]

Že by objekt v jazyce BrainFuck?

[Michal Vyskočil]

A pak me presvedcujte o tom, ze Python (a dalsi podobne jazyky ala Java, C++, vcetne meho oblibeneho Perlu) jsou objektove orientovane jazyky. Smalltalk na vas.

No ta odpověď byla zavádějící, protože v Pythonu jsou řetězce i seznamy objekty (jako prakticky všechno, co tam je). Rozdílem je, že změna immutable objektu vytvoří jeho novou instanci, kdežto změna seznamu ne.

pouzivanim prasaren jako

re.search("c", "abcdef")

Z toho se zacatecnik akorat nauci, ze ma delat vlastni tridu, kterou bude jenom zastresovat nejaky vetsi akce, pak vytvori jenom jeden objekt tehle tridy a tam bude volat tyhle svoje metody vzdy s parametrama, misto aby vytvoril vlastni tridu, kterou vytvori rozsirenim nejaky originalni tridy a do ty pak prida vlastni metody a ty bude pak volat na ten konkretni objekt, napr. ten regular vyse by mel byt spravne

"abcdef".search("c")

Není hezké kritizovat Python, pokud o něm nic nevím . To re není instance třídy, nýbrž modul, který poskytuje funkci search. Ten modul dokonce poskytuje funkce pro vytvoření pattern objektu, takže se dá napsat i tento kód

pat = re.compile("c")
pat.search("abcdef")

Potom je pochopitelně otázka, zda nemá každá instance třídy string poskytovat i podporu pro regulární výrazy, ale Python obecně inklinuje k malým třídám a implementaci pomocí skládání, nikoli dědičnosti, takže v něm neexistují košaté rodiny různých tříd jako to má Smalltalk, Java, nebo Ruby.