On 2 Lip, 22:40, Rob Wolfe <r...@s...pl> wrote:
> Zbigniew Zagórski <z...@g...com> writes:
> > On 2 Lip, 14:01, "didi" <d...@d...com> wrote:
> >> Użytkownik "didi" <d...@d...com> napisał w
wiadomościnews:h2hvke$456$1@news.wp.pl...
>
> >> > outfile=open("name.txt",'w')
> >> > for file in filenames:
> >> >    text=open(file)
> >> >    lines=text.readlines()
> >> >    outfile.writelines(lines[3:])  #zapisz wszystkie linie począwszy od
> >> > 3-ciej
> >> >    text.close
> >> > outfile.close
>
> >> > I problem jaki napotkałem to UnicodeDecodeError: 'charmap' codec can't
> >> > decode byte ... in position ...:character mapt to <undifined>
>
> >> Zamiast Pythona 3xx użyłem wersję 2xx, które z defaultu nie konwertuje do
> >> postaci Unicode.
>
> > Oj wygląda na to, że Python zmierza w złym kierunku ... Szkoda.
>
> Taki wielgachny wnioch na podstawie tak drobnego nieporozumienia? ;)

No może trochę za wielgachny... Ale i tak trochę mi śmierdzi ... o tym
niżej

>
> > Przeczytałem twój post jakiś czas temu i zastanawiałem się jak to
> > możliwe...
> > 100 razy pisałem coś podobnego i działało.
>
> > A tu okazuje się, że dla Pythona NG wszystko to tekst. Brawo... No i
> > brawo
>
> No chyba po to wymyślono dwa tryby otwarcia pliku:
> (...)
> Masz na myśli stabilne API pomiędzy 2.x i 3.x?
> Cały sens powstania wersji 3.x sprowadza się do tego,
> aby nie być zmuszonym wstecznej kompatybilności z 2.x.
> Akurat w kwestii I/O i "bajty vs stringi vs unicode" w 3.x nastąpiły
> bardzo znaczące zmiany:http://docs.python.org/3.1/whatsnew/3.0.html#
text-vs-data-instead-of-...

Zgoda ...

> Aczkolwiek nie jakieś znowu rewolucyjne. Model bardzo zbliżony do java'owego.
> W tym konkretnym przypadku, który doprowadził Cię do tak drastycznych
> wniosków wystarczyło zamiast:
>
> open(file)
>
> napisać:
>
> open(file, errors='replace')

No sorka, to jest odczytywanie z translacją. Całkowicie odpada.

> co jest napisane wołami w dokumentacji.
> Java różni się tym, że przy błędnym kodowaniu nie rzuca wyjątku,
> lecz traktuje taką sytuację jako niezdefiniowaną.
> Python dodaje tu dodatkową możliwość kontroli i jeszcze zbiera
> za to cięgi. Echhh... ;)

Przeczytałem o tym wszystkim - po napisaniu postu - i ... oryginalny
poster pisał coś o tym, że próbował open(...,"rb"), i że też nie
działa.
Wygląda na to, że to on nie przeczytał dokumentacji - ani nie
pochwalił
się, że odpala to na py3k.

A wracając do cięgów. Nie siedzę ostatnio w Pythonie - jakoś mi się
z nim drogi rozeszły ale ... (nie czytałem żadnego flejma na ten temat
Py3k
więc opinia jest bardzo "IMHO") i tak uważam, że włożenie Unicode do
"normalnych" plików - i to domyślnie - jest nie na miejscu. Kodowanie
I/O
jest rzeczą wysoce zależną od aplikacji i powinno być używane w sposób
świadomy a nie gdzieś pod spodem korzystając z aktualnego locale.
To nie jest sprawa języka tylko projektu biblioteki. Mogli zostawić
jak było (czyli domyślnie "bytes") bez szkody dla innowacyjności Py3k
jako całości.

Z drugiej, strony podział na "text" i "bytes" (czy jak to tam
było) jest świetnym posunięciem.

BR,
ZZ