Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
radek napsal(a):
> Avšak souhlasím s názorem, že soubory se čtou
> většinou po řádcích takže je
> to takto praktické ale mám z toho pocit vyjímky která se mi nelíbí.
Problém je v tom, že zadrátovat do jazyka konstrukci, která ušetří
několik písmenek je sice praktické, ale nedobré. Nechť je prostě všechni
vidět. Pokud se soubory mohou číst i jinak, než po řádcích, což se děje
velmi často, tak bych tyto zjednodušující konstrukce do jazyka vůbec
nedával.
Presne tak, priklady, jak by to vypadalo jinak:
#cteni po radcich s defaultnim line oddelovacem (jak je ted)
for line in file("data.txt").lines():
...
#cteni po radcich, ktere jsou oddelene oddelovacem
for line in file("data.txt").lines(""):
[...]
Ale definice, že řádek v textovém souboru je ukončen
jaksi není obecně přijímaná. Když chci, musím
si to napsat sám a nebo použít odpovídající parser.
Jan Matějka
Ono obecnější řešení je udělat parsovací generátory, které by šly použít s
čímkoliv file-like jako vstupním prametrem, a nestrkat parsování to objektu
file. Tedy: [...]
for line in lines(file("data.txt")):
...
[...] atd.
Výpočetní náročnost by zústala stejná. Generátory mi přijdou jako skvělý
nástroj, škoda že se GvR brání zobecnění do více úrovní zanoření jenž nabízí
stackless python.
Ale vdyť mi nic nebrání zpracovávat soubor po znacích.
# Vygenerujeme si testovaci textovy soubor.
f = open('test.txt', 'w')
for i in xrange(3):
f.write('Line %d.\n' % i)
f.close()
# Pruchod po znacich.
f = open('test.txt')
c = 'init'
while c != '':
c = f.read(1)
print c
f.close()
A nic mi nebrání napsat generátor, který vezme a bude vracet znaky
a použít ho:
def chargen(f):
c = 'init'
while c != '':
c = f.read(1)
yield c
for c in chargen(file('test.txt')):
print c
A můžu si napsat jakýkoliv jiný generátor/parser.
pepr
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python
Visit: http://www.py.cz
Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
radek napsal(a):
>> > Avšak souhlasím s názorem, že soubory se čtou
>> > většinou po řádcích takže je
>> > to takto praktické ale mám z toho pocit vyjímky která se mi nelíbí.
>>
>> Problém je v tom, že zadrátovat do jazyka konstrukci, která ušetří
>> několik písmenek je sice praktické, ale nedobré. Nechť je prostě všechni
>> vidět. Pokud se soubory mohou číst i jinak, než po řádcích, což se děje
>> velmi často, tak bych tyto zjednodušující konstrukce do jazyka vůbec
>> nedával.
>>
>
> Presne tak, priklady, jak by to vypadalo jinak:
>
> #cteni po radcich s defaultnim line oddelovacem (jak je ted)
> for line in file("data.txt").lines():
> ...
>
> #cteni po radcich, ktere jsou oddelene oddelovacem
> for line in file("data.txt").lines(""):
> [...]
Ale definice, že řádek v textovém souboru je ukončen
jaksi není obecně přijímaná. Když chci, musím
si to napsat sám a nebo použít odpovídající parser.
Jan Matějka
> Ono obecnější řešení je udělat parsovací generátory, které by šly použít s
> čímkoliv file-like jako vstupním prametrem, a nestrkat parsování to objektu
> file. Tedy: [...]
>
> for line in lines(file("data.txt")):
> ...
> [...] atd.
>
> Výpočetní náročnost by zústala stejná. Generátory mi přijdou jako skvělý
> nástroj, škoda že se GvR brání zobecnění do více úrovní zanoření jenž nabízí
> stackless python.
Ale vdyť mi nic nebrání zpracovávat soubor po znacích.
# Vygenerujeme si testovaci textovy soubor.
f = open('test.txt', 'w')
for i in xrange(3):
f.write('Line %d.\n' % i)
f.close()
# Pruchod po znacich.
f = open('test.txt')
c = 'init'
while c != '':
c = f.read(1)
print c
f.close()
A nic mi nebrání napsat generátor, který vezme a bude vracet znaky
a použít ho:
def chargen(f):
c = 'init'
while c != '':
c = f.read(1)
yield c
for c in chargen(file('test.txt')):
print c
A můžu si napsat jakýkoliv jiný generátor/parser.
pepr
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
Tak tohle by bylo žůžo, to by se mi moc zamlouvalo. Bylo by to skvělé a
obecné řešení. Jenže bohužel to asi není v Perlu, takže od GvR máme
smůlu. :-(
S takovýmto řešením by se podle mě vyřešila jako vedlejší efekti i řada
dalších konstrukcí a dalo by se to použít k řadě dalším věcem.
Miloslav Ponkrác
Jan Matejka napsal(a):
> Ono obecnější řešení je udělat parsovací generátory, které by šly použít s
> čímkoliv file-like jako vstupním prametrem, a nestrkat parsování to objektu
> file. Tedy:
>
> místo
>
>>for line in file("data.txt").lines():
>> ...
>
>
> by bylo:
> for line in lines(file("data.txt")):
> ...
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
Ono obecnější řešení je udělat parsovací generátory, které by šly použít s
čímkoliv file-like jako vstupním prametrem, a nestrkat parsování to objektu
file. Tedy:
místo
> for line in file("data.txt").lines():
> ...
by bylo:
for line in lines(file("data.txt")):
...
místo
> #cteni po UTF znacich
> for char in file("data.txt").chars():
by bylo:
for char in chars(file("data.txt")):
atd.
Výpočetní náročnost by zústala stejná. Generátory mi přijdou jako skvělý
nástroj, škoda že se GvR brání zobecnění do více úrovní zanoření jenž nabízí
stackless python.
Jan Matějka
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
> > Avšak souhlasím s názorem, že soubory se čtou většinou po řádcích takže je
> > to takto praktické ale mám z toho pocit vyjímky která se mi nelíbí.
>
> Problém je v tom, že zadrátovat do jazyka konstrukci, která ušetří
> několik písmenek je sice praktické, ale nedobré. Nechť je prostě všechni
> vidět. Pokud se soubory mohou číst i jinak, než po řádcích, což se děje
> velmi často, tak bych tyto zjednodušující konstrukce do jazyka vůbec
> nedával.
>
Presne tak, priklady, jak by to vypadalo jinak:
#cteni po radcich s defaultnim line oddelovacem (jak je ted)
for line in file("data.txt").lines():
...
#cteni po radcich, ktere jsou oddelene oddelovacem
for line in file("data.txt").lines(""):
...
#cteni po UTF znacich
for char in file("data.txt").chars():
...
#cteni po bytech
for byte in file("data.txt").bytes():
...
Navic by ty metody s defaultnim parametrem mohly byt propagovane jako
atributy, tedy napr.:
for line in file("data.txt").lines:
...
Radek
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
> Díky za reakci, > dle mého nedišputovatelného gusta uvedené věty s vyjímkou > Simple is better than complex > Although practicality beats purity > svědčí spíš pro styl xreadlines hlavně proto že tam je ten slovní základ > "lines". Já s tím také souhlasím. Ale pokud je xreadlines jenom deprecated, pak nic nenamítám, pokud tam zůstane. V takové Javě jsou deprecated věci klidně už desátým rokem, ale nikdo si je nedovolí vyhodit. Jinak se mi vůbec nelíbí ten Perlovský implicitní styl, kdy prostě každý objekt v nějakém kontextu něco nečekaného (rozuměj implicitního) provede. Čím dál víc se mi zdá, že GvR se bohužel asi v Perlu vidí. Takto mohou také vznikat dost ošklivé chyby a k=od se stane hůře udržovatelným. > Avšak souhlasím s názorem, že soubory se čtou většinou po řádcích takže je > to takto praktické ale mám z toho pocit vyjímky která se mi nelíbí. Problém je v tom, že zadrátovat do jazyka konstrukci, která ušetří několik písmenek je sice praktické, ale nedobré. Nechť je prostě všechni vidět. Pokud se soubory mohou číst i jinak, než po řádcích, což se děje velmi často, tak bych tyto zjednodušující konstrukce do jazyka vůbec nedával. Miloslav Ponkrác ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
Re: [python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
> Petr Prikryl > A k té explicitnosti -- místo xreadlines() bych sice mohl > psát __iter__(), ale... > > "The Zen of Python, by Tim Peters > > Beautiful is better than ugly. > Simple is better than complex. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity." Díky za reakci, dle mého nedišputovatelného gusta uvedené věty s vyjímkou Simple is better than complex Although practicality beats purity svědčí spíš pro styl xreadlines hlavně proto že tam je ten slovní základ "lines". Avšak souhlasím s názorem, že soubory se čtou většinou po řádcích takže je to takto praktické ale mám z toho pocit vyjímky která se mi nelíbí. Jan Matějka ___ Python mailing list Python@py.cz http://www.py.cz/mailman/listinfo/python
[python] file.next() (bylo Buducnost Pythonu: lambda, map, filter)
Jan Matejka
> [...] je to spíš jako
> for line in f.xreadlines():
>
> Kde xreadlines() vrací iterátor, který čte soubor
> postupně na rozdíl od readlines který přečte soubor
> najednou do seznamu řádků.
>
> Přidám se ale k nadávání na odstraňování starých prvků
> jazyka. Xreadlines je od verze 2.3 označeno za zastaralé.
>
> for line in file("data.txt").xreadlines():
> ...
>
> se mi líbí víc než preferované
> for line in file('data.txt')
> ...
>
> protože "explicit is better than implicit". Xreadlines()
> totiž vyjadřuje že se čte po řádcích a nikoliv po bytech,
> unicode znacích nebo co já vím jakých jednotkách v souboru.
3.9 File Objects
next( )
A file object is its own iterator, for example iter(f)
returns f (unless f is closed). When a file is used as
an iterator, typically in a for loop (for example,
for line in f: print line), the next() method is called
repeatedly. This method returns the next input line,
or raises StopIteration when EOF is hit. In order to make
a for loop the most efficient way of looping over the lines
of a file (a very common operation), the next() method
uses a hidden read-ahead buffer.
Volný překlad: Objekt typu soubor je svým vlastním
iterátorem. Takže například iter(f) vrací f (pokud f
není uzavřen). Pokud je souborový objekt použit
jako iterátor -- typicky v cyklu for (například
for line in f: print line), volá se opakovaně metoda next().
Tato metoda vrací další vstupní řádek nebo na konci
vyvolá výjimku StopIteration. Aby cyklus for mohl
řádky souboru procházet co nejefektivněji (jde o velmi
běžnou operaci), používá metoda next() skrytou vyrovnávací
paměť pro načítání dat předem.
A k té explicitnosti -- místo xreadlines() bych sice
mohl psát __iter__(), ale...
"The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Simple is better than complex.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity."
pepr
___
Python mailing list
Python@py.cz
http://www.py.cz/mailman/listinfo/python
