Dotaz: Python - prace s pameti

[George O.]

Příloha:

• test.py (1224 bytů)

Zdravim, nedavno jsem tu resil parsovani html documentu, avsak jsem se dostal jakozto python zelenac do situace, kterou neumim resit, protoze presne nechapu, jak python pracuje s pameti, konkretne kopirovani obsahu vs adresy nebo aspon myslim, ze prave tohle je pricinou nespravne funkcnosti me casti kodu.

V priloze jsou dva kratke soubory a to "test.py", ktery predstavuje funkcni, ale neefektivni reseni pres n-dimenzni pole a "test2.py" reseni, ktere chci realizovat, ale je ponekud nefukcni - chovani je vysvetleno na poslednim radku v komentari

Vsem moc diky za cas a pomoc

PS: nemuzu vlozit vice, jak jednu prilohu, takze "test2.py" bude v reakci.

Odpovědi

[George O.]

Příloha:

• test2.py (2255 bytů)

Zde je test2.py

[l4m4]

Mi se to teda moc nechce číst...

Jednak tam máš problém s defaultními hodnotami argumentů, které jsou modifikovatelné typy (attrs = {}). Ta defaultní hodnota je konkrétní modifikovatelný objekt, takže zkus:

def f(x, a=[]):
    a.append(x)
    print(len(a))

f(1)
f('ble')
f(None)

Dále:

Všechno se předává referencí. Tedy všechno s čím pracuješ, jsou jména objektů, ne hodnoty.

Existují modifikovatelné a nemodifikovatelné objekty.

Nemodifikovatelné (např. čísla, stringy, None, ...) se chovají de facto jako hodnoty, ale právě jen proto, že nejdou modifikovat. Po x=1 jsou x a 1 jen jiná jména pro týž objekt. Po x+=1 bude x jméno pro jiný nemodifikovatelný objekt, nezmění se žádná hodnota x.

A u modifikovatelných je to pak samozřejmě velký rozdíl. Chceš-li kopii, použij modul copy (např.).

[pavlix]

Všechno se předává referencí. Tedy všechno s čím pracuješ, jsou jména objektů, ne hodnoty.

Technicky vzato se vše předává hodnotou, která obsahuje referenci (tedy lokální název obsahuje stejnou referenci na objekt, jako „skutečný“ parametr). Předává se tedy (reference na) objekt, ne proměnná jako taková.

Souhlasím s tím, že většina problémů bude způsobena tím, že se použije stejný měnitelný objekt, kde si programátor myslí, že se mu vytvoří nový objekt.

[rADOn]

1. V pythonu žádné „předávání obsahu“ není. Všechno co vidíš jsou jen jména ve jmenných prostorech která jsou odkazem na nějaký objekt. I primitivní datové typy jako int jsou objekty, každé jméno které vidíš je odkaz na nějakou instanci.
2. chyba bude asi tady:

   def __init__(self, name, parent, attrs = {})
       self.__attrs = attrs

   slovník attrs se ti zkonstruje pouze jednou v okamžiku definice té funkce, všechny instance si následně přiřadí do svého jmenného prostoru referenci na tentýž slovník. Správně se to dělá takhle:

   def __init__(self, name, parent, attrs = None)
       self.attrs = attrs if attrs is not None else {} 

3. Pokud si chceš sestavit uzly jako strom objektů v paměti, je to už ve standartní knihovně.
4. Rada do života jako bonus: Nepiš gettery a settery! Je to nepřehledný hnus a zbytečně to zpomaluje. (Volání metody je v pythonu relativně drahá operace.) Pokud budeš někdy v budoucnu potřebovat udělat getter nebo setter, přístup k atributu se dá zachytit pomocí @property dekorátoru. To ostatně platí obecně – pythoní kód je stručný výstižný, pokud se přistihneš že píšeš nudnou "omáčku" ve stylu Javy tak děláš něco špatně.

[Kit]

Rada do života jako bonus: Nepiš gettery a settery! Je to nepřehledný hnus a zbytečně to zpomaluje. (Volání metody je v pythonu relativně drahá operace.) Pokud budeš někdy v budoucnu potřebovat udělat getter nebo setter, přístup k atributu se dá zachytit pomocí @property dekorátoru. To ostatně platí obecně – pythoní kód je stručný výstižný, pokud se přistihneš že píšeš nudnou "omáčku" ve stylu Javy tak děláš něco špatně.

Gettery a settery jsou zločin i v Javě. Je to jasná ukázka, že dotyčný programátor neumí programovat objektově.

[kuka]

a objektove se k hodnotam atributu v jave pristupuje jak?

[Kit]

A proč bych měl přistupovat k hodnotám atributů objektu? K čemu je budu potřebovat?

Je potřeba si uvědomit, že použití getteru nebo setteru je stejně špatné jako public přístup k atributu objektu. Z objektu přece nevybíráme hodnoty atributů ani je nenastavujeme. Objektům se posílají zprávy o událostech a získávají se od nich reporty.

[l4m4]

A proč bych měl přistupovat k hodnotám atributů objektu?

Protože Python nemá POD (plain old data) schopná snadno a rychle shrnout skupinu informací do jedné ,věci`. Tudíž zbývá

# Dal jsem to do čtvrté položky, nebo do šesté?  Ale kdeže, do třetí.
struct = (1.2, -3.0, 'cx', 4, 4, 0, True, False, True)
print struct[3]

# Složitý přístup k datům máme rádi, nutí nás zamyslet se, zda je opravdu potřebujeme.
struct = {
   'alpha': 1.2, 'lambda': -3.0,
   'name': 'cx',
   'width': 4, 'height': 4, 'depth': 0,
   'normalize': True, 'recursive': False, 'fixed': True,
}
print struct['width']

# Jsem expert, tak vyrobím něco, co se dá indexovat a sčítat jako tuple, abych vás zmátl.
import collections
Struct = collections.namedtuple('Struct', bla bla bla...)
bla bla bla...

# Ecce obiectum!  Není to POD, ale je to skoro tak dobré.
class Struct:
    def __init__(self, **kwargs):
        self.__dict__.update(kwargs)

struct = Struct(alpha=1.2, beta=-3.0, name='cx', width=4, height=4, depth=0,
                normalize=True, recusrive=False, fixed=True)
print struct.width

Navzdory ortodoxním objektistům nechci té věci posílat zprávy, chci s ní něco udělat (viz Execution in the Kingdom of Nouns). Právě proto, aby to nevypadalo jako typická javí byrokracie.

[Kit]

A proč bych měl přistupovat k hodnotám atributů objektu?

...
print struct.width

Někdy je také dobré se zamyslet, k čemu vlastně potřebuji struct.width. Často je to zaviněno chybným návrhem objektu. Obvykle totiž samotné atributy objektu ve své podstatě nepotřebuji.

[l4m4]

Četl jsi to vůbec? Nenavrhuji žádný objekt. Při čemkoli, co v Pythonu děláš, vznikne spousta objektů, což neznamená, že je navrhuješ.

[Kit]

Nenavrhuješ objekt, ale vytváříš datovou strukturu. I když je to po technické stránce objekt, má do objektu daleko. Nic nedělá, jen uchovává data.

[l4m4]

Výborně. A to je přesně ta situace, kdy vytvářím objekt -- protože nic jiného vytvořit nejde -- jen proto, abych přistupoval k jeho datovým členům. Stejně jako pole vytvářím často proto, abych přistupoval k jeho položkám (někdy se využijí i metody pole).

[Kit]

Dobrá, máš tedy datovou strukturu. Ale kde máš metody? Plnohodnotné objekty přece obsahují datové struktury a metody, které jediné s nimi mohou pracovat. Gettery a settery mezi metody nepočítám. Jsou jen nadstavbou datové struktury, aby přímý přístup k ní nevypadal tak blbě.

[diverman]

Gettery a settery mezi metody nepočítám. Jsou jen nadstavbou datové struktury, aby přímý přístup k ní nevypadal tak blbě.

Blbost. V setteru bezne provadim vedlejsi efekty, napr. logging. Navic python pomoci property() vytvari tak dokonalou hracku, ze se to primo vybizi takto primo pristupovat k atributum objektu.

[Kit]

Už jsme si to vyjasnili jinde. Byly myšleny primitivní gettery a settery v uvedeném příkladu, které jen nahrazovaly přímý přístup k datové struktuře a nedělaly nic navíc.

[pavlix]

Byly myšleny primitivní gettery a settery v uvedeném příkladu, které jen nahrazovaly přímý přístup k datové struktuře a nedělaly nic navíc.

Což je ovšem velmi nezajímavé téma, o kterém si tu podle mě chce povídat jen jeden jediný člověk.

[pavlix]

I když je to po technické stránce objekt, má do objektu daleko.

Ach ta terminologie :).

[kuka]

Aha a kdyz budeme chtit z objektu reprezentujiciho treba zamestnance ziskat jeho prijmeni, tak to udelame jak?

[Kit]

Především se zamyslím nad tím, k čemu mi bude jenom jeho příjmení a co s ním vlastně chci dělat. Objekt není jen datové skladiště, do kterého ukládám elementární údaje a zase je vybírám. Objekty toho umí mnohem víc.

Pokud budu z objektu potřebovat jen příjmení zaměstnance, tak zbývající údaje o zaměstnanci jsou zbytečné. Nepotřebuji tedy objekt, ale bude mi stačit jedna proměnná typu string, do které umístím příjmení.

[George O.]

Gettery a Settery jsou docela dobra vec, pokud clovek chce udrzet nejakou konzistenci a access policy. Soucasny priklad byl maximalne zjednoduseny, abych vyloucil zbytecne logicke chyby. Kazdopadne uz jsem si nastudoval dekoratory a docela fajnova vec to je

Ale kazdopadne nic to nemeni na tom, ze se mi nedari zrealizovat klasicky seznam-like datovou strukturu - priklad:

typedef struct list {
  char *data;
  struct list *next;
} LIST;

Ja se teda snazim presneji o tohle, coz sice neni to same, ale napadne podobne:

typedef struct list {
  char *data;
  struct list *parent;
  struct list **children;
} LIST;

Ale neprisel jsem na to, jak to zrealizovat v pythonu. V PHP to bylo hned, ale v pythonu porad tapu a tapu...

[Kit]

Proč na seznam nepoužiješ strukturu seznam?

[George O.]

Protoze seznam nema reference mezi objekty nebo snad ano? A jinak pokud sis vsiml, tohle byla tree struktura, ale mela podobne vlastnosti, jako seznam - to jest reference na sebe sama

[rADOn]

Protoze seznam nema reference mezi objekty nebo snad ano?

Který části tvrzení „v pythonu je všechno reference“ nerozumíš? Sleduj lva:

In [10]: l = [1,2,3]

In [11]: l.append(l)

In [12]: l
Out[12]: [1, 2, 3, [...]]

(tři tečky jsou objekt Elipsis který značí zacyklení)

[pavlix]

Ale kazdopadne nic to nemeni na tom, ze se mi nedari zrealizovat klasicky seznam-like datovou strukturu - priklad:

typedef struct list {
  char *data;
  struct list *next;
} LIST;

Definuj „nedaří se mi“, mně totiž nenapadá, co by se ti na tom mohlo nedařit. Atribut data nastavit můžeš, atribut next jakbysmet, takže?

[George O.]

Odpoved najdes v "test2.py" (2. reakce, v teto diskuzi)

[rADOn]

Tam máš ale úplně jinou chybu.

[pavlix]

Odpoved najdes v "test2.py" (2. reakce, v teto diskuzi)

Pokud nemáš zájem o pomoc, stačí to říct rovnou :).

[kuka]

Takze pokud na konkretnim miste systemu potrebuju zrovna jen prijmeni, tak vsechno ostatni je zbytecne? Na jinem miste muze byt potreba neco jineho. Spravny objektovy pristup by tedy spocival v tom, ze prijmeni zamestnance budu mit nekde uplne jinde nez v instanci tridy zamestnanec (kde?) v promenne typu string?

[Kit]

Je mi podivné, proč bych měl chtít z instance třídy zaměstnanec jen příjmení zaměstnance. Jiné údaje mě nezajímají? Ani osobní číslo? Vůbec nic s tím příjmením nepotřebuji dělat, jenom ho chci vytáhnout z objektu? K čemu mi pak bude, když ho na nic nepotřebuji?

[l4m4]

Chci ho vypsat na stdout. Tak.

[l4m4]

Nebo naopak: K čemu potom ten objekt drží to příjmení, když ho od něj nesmím chtít?

[Kit]

Třeba můžu po tom objektu chtít, aby to příjmení vypsal na stdout. Nebo po něm můžu chtít, aby na ten stdout vypsal celé jméno, příjmení, adresu a aby to správně naformátoval. Také po něm můžu chtít, aby mi to poslal jako string nebo strukturu.

Nelíbí se mi, když kdekdo do třídy paušálně nacpe gettery a settery na každou položku, ke které možná bude chtít přistupovat z vnějšku. Je to stejně špatné, jako použití public proměnných. Jen to vypadá jinak.

[pavlix]

Nelíbí se mi, když kdekdo do třídy paušálně nacpe gettery a settery na každou položku, ke které možná bude chtít přistupovat z vnějšku. Je to stejně špatné, jako použití public proměnných. Jen to vypadá jinak.

Nebo taky stejně správně :).

[Kit]

Kdybych napsal "stejně správně", tak by to možná vypadalo, jako kdybych obhajoval public proměnné. A k tomu mám hodně daleko. Objekt má být černá skříňka, která v maximální míře skrývá svou strukturu, reaguje na události a poskytuje reporty.

[pavlix]

Kdysi jsem byl taky víc filosof než programátor, ale v poslední době jsem tyhle složky osobnosti spíše vyrovnal :).

[kuka]

Ovsem o zadnem pausalnim cpani getteru (a uz vubec ne setteru) do tridy nebylo vubec reci, to je pouze jakasi tvoje sugesce. Jak se lisi metoda napr. getPrijmeni od "aby mi to poslal jako string"? Mne se zase nelibi, kdyz nekdo pausalne predpoklada, ze ostatni jsou blbci, a placa hovadiny jako "pouziti getteru je stejne spatne jako public pristup k atributu".

[Kit]

Pod pojmem getter chápu metodu, ve které je pouze

return this.prijmeni;

a takové metody se mi nelíbí, protože nic nedělají. Možná to chápeš jinak.

Velmi často se setkávám s tím, že v aplikaci je getter osoba.getPrijmeni(), o řádek níž osoba.getJmeno() a na dalším je jejich spojování a výstup. Proč tak složitě, když to může udělat objekt?

Se settery to bývá stejné. Nejprve vytvoření prázdného objektu, potom hromada setterů. Přitom by stačilo jedním příkazem vytvořit naplněný objekt v konstruktoru.

Další příklad. Připočtení hodnoty k atributu objektu. Běžně vídám tuto hrůzu:

objekt.setX(objekt.getX+5);

místo praktičtějšího

objekt.addX(5);

nebo

objekt.posunDoprava(5);

případně

objekt.posun(5,kurs);

[kuka]

Co bezne vidas je irelevantni a getter chapes zjednodusene (i tak ale byva konkretne v jave lepsi takovy trivialni getter nez primy pristup k promenne). Gettery a settery umoznuji pristup k properties (tzn. pochopitelne nijak nesupluji metody ala "posunDoprava"). Property muze byt cokoliv a technicky nemusi byt ve tride nijak reprezentovana. Napriklad zamestnanec muze mit property "cele jmeno", ovsem datove obsahuje zvlast jmeno a prijmeni, ktere se pro potreby ziskani celeho jmena spoji a volajicimu do toho vubec nic neni. Setter pro takovou property pak neobsahuje vubec a nemusi ho obsahovat ani pro prijmeni (to je ostatne caste, nemodifikovatelne tridy neposkytuji settery ani jine mutatory). To je prave rozdil proti primemu pristupu k instance variables - getter nebo setter muze obsahovat logiku, kontrolu pristupu, logovani... Muze byt take jednoduse obalen aspektem, coz uz je ale offtopic. Pouziti getteru je zkratka velmi objektove, protoze zakryva implementaci.

[Kit]

Dobrá. Asi jsem měl spíš použít slovní spojení "primitivní getter" a "primitivní setter", která snad lépe vystihují, co jsem měl na mysli.

Souhlasím, že objekt vůbec nemusí dané atributy obsahovat ve formě proměnných. Settery a gettery mohou například přímo komunikovat s databází.

Ovšem nevidím důvod, proč by podle tebe nemohl existovat setter setCeleJmeno("Jmeno","Prijmeni")

[kuka]

Tak ja netvrdim, ze nemuze nikdy existovat. Metodicky to ale neni ciste, protoze jestlize je property odvozena, tak se jeji hodnota jako takova nenastavuje. Pritom muze byt klidne v poradku poskytnout metodu, ktera nastavuje jmeno i prijmeni, pouze jeji "vydavani" za setter jakesi jine property je matouci, metoda by se mohla jmenovat treba changeJmenoPrijmeni. Je to spis otazka nejakych best practices pri modelovani, kde by rekneme pro trivialniho zamestnance mohly byt read-write properties jmeno a prijmeni a read-only property celeJmeno, u niz by byl popsan konkretni format (treba prijmeni uppercase, zarovnani a pripadne zkraceni krestniho jmena apod.).

[Kit]

Vzhledem k tomu, že většinou konstruktorem rovnou ukládám položku do databáze, tak už musím mít k dispozici všechny potřebné atributy, abych chybějící položky nemusel v databázi nahrazovat správným údajem. Takže pak už to ani nenazývám jako setter, ale jako konstruktor. Setterem tu položku jen modifikuji nebo mažu, ale nepřidávám.

[kuka]

Tak proc ne, at me tedy zajima prijmeni, jmeno, osobni cislo a cislo bot - na situaci to meni co?

[Pavel Stárek]

Asi tomu nerozumím. Tedy je špatně když si napíšu takovouhle třídu se kterou budu někde dále v programu pracovat?

class Zamestnanec(object):
  def __init__(self):
    self.jmeno = u""
    self.prijmeni = u""
    self.pozice = u""

[Kit]

Připadá mi podivné vytvářet objekt třídy Zamestnanec, který nemá jméno, příjmení ani pozici. Dokonce místo nedefinovaných hodnot má nějaké prázdné řetězce. To už byl mnohem lepší konstruktor, který sem poslal l4m4.

[Pavel Stárek]

No vidím, že pán je programátor. Takže tady bude každá další diskuze zbytečná.

[George O.]

No, treba ma jen jiny pohled na problem. Mozna mu prijde efektivnejsi hash array s externim workflow a zadnym rizenim pristupu

[Kit]

Právě naopak. Gettery a settery považuji za nežádoucí externí workflow, protože nic nedělají. Pouze zpřístupňují interní proměnné objektu.

[pavlix]

Já měl vždy za to, že vznikly pro případ, že něco dělají.

[pavlix]

Tak s tím nesmyslným prázdným zaměstnancem by se dalo celkem souhlasit, ne?

[Pavel Stárek]

A co když si tam ta data chci dát někdy jindy?

[pavlix]

Je nějaký důvod, proč na to někdy jindy neodložit vytvoření toho záznamu?

[Kit]

Podle mne není. Obvykle je zbytečné vytvářet prázdné objekty a teprve dodatečně je plnit. V reálném životě to nikdo nedělá. Proč to zavádět v programování? Konstruktory jsou tu od toho, abychom je používali.

[Pavel Stárek]

A jen tak pro zajímavost, to není objekt, alébrž třída.

[Milan Roubal]

podle me je ten vysledek 2 soucet title + script a nikoliv head + body. Rekl bych, ze to dela ten radek odstraneni prvniho elementu.

U toho druheho prikladu jsou vsechny objekty HtmlElement jeden a ten samy objekt, proto to neudela strom.

[Bystroushaak]

Jen doplním, že kdyby někdo nechtěl zabíjet čas psaním vlastního parseru, existuje BeautifulSoup, nebo můj pyDHTMLParser.

[George O.]

Anebo taky existuje http://docs.python.org/library/htmlparser.html coz je zakladni knihovna pythonu... a je spolehlivy

[Bystroushaak]

Jenže má jednu nevýhodu - autoři při jeho návrhu fetovali.

Pro různé spidery a celkově stránky, u kterých dopředu nemůžeš, nebo jsi moc líný namodelovat strukturu se víc hodí ty mnou odkazované.

[Kit]

Zajímalo by mě, co konkrétně je na modulu HTMLParser špatně. Podle mne je to běžné parsování metodou SAX. Každý token vyvolá nějakou událost, kterou si zpracuješ podle potřeby.

[Bystroushaak]

Podle mne je to běžné parsování metodou SAX. Každý token vyvolá nějakou událost, kterou si zpracuješ podle potřeby.

To je na něm špatně.