mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
takich bledow)

generalnie moj bot (w pythonie 2.7)
czyta linijke z czata przez

ircmsg = ircsock.recv(2048)

i nic na tym nie robie nie wywoluje ani zadnego decode ani encode

i np polskie litery w tym dzialaja (są) choc nie wiem jaki to format, moge wyciac z
tego np kawalek i wyslac do translatora google, odeslany tekst tez zawiera egzotyczne
znaki

ten wygenerowany tekst odsylam przez

ircsock.send(s.encode('UTF-8'))

bez tego encode to to raczej nie dziala
ale z tym encode dziala

problem pojawia sie gdy te linijki w srodku
wstawiam do slownika ktory zapisuje do pliku json na dysk

czytam i zapisuje ten json ze tak powiem normalnie bez zadnych udziwnien

bo jesli chce dodac "KóKó" do tego slowniek ai zapisac toz apisze sie to normalnie,
natomiast gdy chce to odczytac i wyslac na kanal to robie

s = bot_memory[key]
say(s.decode('UTF-8'))

bez tego decode nie dziala (leci blad)
z tym decode co prawda tez leci blad tylko inny

(przy czym moze dodam ze slownik czytam tylko raz na strcie programu z dsku,
natomiast zapisuje przy kazdym wstawieniu tekstu)

jesli jest to decode to moge zapisywac wpisy na dysk i moge je czytac ze slowniek i
wyswietlac na kanal - ale tylko poki nie zamkne bota i nie wczytam tego z dysku,
wtedy przy probie odczytania wpisu i wyslania go na kanal z tego leci blad (ascii
codect cant encode...)

z kolei jak to decode wywale jest
odwrotnie, po uruchomieniu boyta moge
wysylac zapisane za poprzednim razem wpisy na kanal ale nie moge zapisac i odczytac
nowego, tj dokladniej w pliku tez sie zapisuje ale odczytanie go ze slownika i proba
poslania na kanal dale blad (ascii codec cant decode...)

o co tu chodzi? jak to naprawic?

do góry

W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
takich bledow)
>
> generalnie moj bot (w pythonie 2.7)
> czyta linijke z czata przez
>
> ircmsg = ircsock.recv(2048)
>
> i nic na tym nie robie nie wywoluje ani zadnego decode ani encode
>
> i np polskie litery w tym dzialaja (są) choc nie wiem jaki to format, moge wyciac
z tego np kawalek i wyslac do translatora google, odeslany tekst tez zawiera
egzotyczne znaki
>
> ten wygenerowany tekst odsylam przez
>
> ircsock.send(s.encode('UTF-8'))
>
> bez tego encode to to raczej nie dziala
> ale z tym encode dziala
>
> problem pojawia sie gdy te linijki w srodku
> wstawiam do slownika ktory zapisuje do pliku json na dysk
>
> czytam i zapisuje ten json ze tak powiem normalnie bez zadnych udziwnien
>
> bo jesli chce dodac "KóKó" do tego slowniek ai zapisac toz apisze sie to normalnie,
natomiast gdy chce to odczytac i wyslac na kanal to robie
>
> s = bot_memory[key]
> say(s.decode('UTF-8'))
>
> bez tego decode nie dziala (leci blad)
> z tym decode co prawda tez leci blad tylko inny
>
> (przy czym moze dodam ze slownik czytam tylko raz na strcie programu z dsku,
natomiast zapisuje przy kazdym wstawieniu tekstu)
>
> jesli jest to decode to moge zapisywac wpisy na dysk i moge je czytac ze slowniek i
wyswietlac na kanal - ale tylko poki nie zamkne bota i nie wczytam tego z dysku,
wtedy przy probie odczytania wpisu i wyslania go na kanal z tego leci blad (ascii
codect cant encode...)
>
> z kolei jak to decode wywale jest
> odwrotnie, po uruchomieniu boyta moge
> wysylac zapisane za poprzednim razem wpisy na kanal ale nie moge zapisac i odczytac
nowego, tj dokladniej w pliku tez sie zapisuje ale odczytanie go ze slownika i proba
poslania na kanal dale blad (ascii codec cant decode...)
>
> o co tu chodzi? jak to naprawic?

ok po napisaniu tego wyzej jakas luzna dedukcja sklonila mnie do wniosku ze skoro w
pliku jest dobrze (a chyab mozna tak zalozyc) to wersja

s = bot_memory[key]
say(s)

jest poprawniejsza (chwilowo te leko zagmatwane dedukcje mi sie lekko zgubily)

i ze widac cos ze wstawianiem do slwnika moze jest nie tak

sprobowalem
bot_memory[key]=value.decode('UTF-8')
save_bot_memory()

przy wstawianiu i chyba dziala ok, nie zebym super do konca rozumial o co tu chodzi

trzeba dodac ze te nazwy encode i decode sa dosyc mylace

wyglada na to ze tw stringi ktore lataja w srodku programu to utf8 , a te wstawiane
do slownika nalezy przerabiac na bajty? inna lekka dziwnosc to tak jakby z tego
socketa do czytania juz wychodzilo utf-8 przy wysylaniu przerabiam na bajty a przy
czytaniu nie musze z bajtow na utf8?

dibrze ze chociaz chyba dziala

do góry

W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
takich bledow)
[...]
> o co tu chodzi? jak to naprawic?

Python 2.7 jest od tego roku oficjalnie niewspierany.
Nie wiem, po co go używać, zwłaszcza do nowego projektu.

Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
poprawione.

Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').

Może pomoże.

do góry

W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com napisał:
> W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do
takich bledow)
> [...]
> > o co tu chodzi? jak to naprawic?
>
> Python 2.7 jest od tego roku oficjalnie niewspierany.
> Nie wiem, po co go używać, zwłaszcza do nowego projektu.
>
> Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
poprawione.
>
> Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
>
> Może pomoże.

powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
glupia - roznie to bywa

ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te starsze sa
czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle szybsze i
prostsze)

moge oczywiscie przeniesc sie i porownac

ten problem chyba naprawilem jak wyzej,
sek w tym ze czasem jak cos koduje to nie bardzo mam czas zatrzymywac sie i
uczyc lyb przemysliwac pewne rzeczy co
poki mam pare jest slusznym wyborem bo
lpiej gnac do przodu
(kiedy sie da, a zatrzymywac kiedy sie nie da.. powinienem moze dodac slowko
'pewnie', pewni elepiej gnac do przodu gdy sie da)

python ogolnie dosyc ciekawy, faktycznie warto sie nauczyc..kodowanie w nim jest
osobliwie bezstresowe, ma sie wrazenie ze te uzywane biblioteczki kompletnie zdejmuja
stres z czlowieka, rowniez reportowanie bledow jest jakies dobre,
za to brakuje pewnych elementow cukru z c

do góry

W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
> W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
napisał:
> > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony
do takich bledow)
> > [...]
> > > o co tu chodzi? jak to naprawic?
> >
> > Python 2.7 jest od tego roku oficjalnie niewspierany.
> > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
> >
> > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
poprawione.
> >
> > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
> >
> > Może pomoże.
>
> powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
> glupia - roznie to bywa

Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie sprawdza.

Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest "lepsze".

> ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te starsze sa
czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle szybsze i
prostsze)

W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
Żadna nie jest bardziej "true" czy "raw".
Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
(Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej skopane, niż
w Pythonie 2)

do góry

W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik g...@g...com napisał:
> W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
> > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
napisał:
> > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony
do takich bledow)
> > > [...]
> > > > o co tu chodzi? jak to naprawic?
> > >
> > > Python 2.7 jest od tego roku oficjalnie niewspierany.
> > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
> > >
> > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach zostało
poprawione.
> > >
> > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
> > >
> > > Może pomoże.
> >
> > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
> > glupia - roznie to bywa
>
> Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie sprawdza.
>
> Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest
"lepsze".
>
> > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te starsze
sa czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle szybsze i
prostsze)
>
> W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
> Żadna nie jest bardziej "true" czy "raw".
> Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
> (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej skopane,
niż w Pythonie 2)

moze kolega podac przyklady i konkretne opinie bo inaczej taka dyskusja jest troche
pusta.. moge przecztac bo sie interesuje oststnie pare dni tym pythionem (poki mi nie
minie pewnia za jakies 2-3 dni)

do góry

W dniu środa, 15 kwietnia 2020 15:01:37 UTC+2 użytkownik fir napisał:
> W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik g...@g...com
napisał:
> > W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
> > > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
napisał:
> > > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> > > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem
przyzwczajony do takich bledow)
> > > > [...]
> > > > > o co tu chodzi? jak to naprawic?
> > > >
> > > > Python 2.7 jest od tego roku oficjalnie niewspierany.
> > > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
> > > >
> > > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach
zostało poprawione.
> > > >
> > > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
> > > >
> > > > Może pomoże.
> > >
> > > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest dosyc
> > > glupia - roznie to bywa
> >
> > Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie
sprawdza.
> >
> > Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest
"lepsze".
> >
> > > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te
starsze sa czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle
szybsze i prostsze)
> >
> > W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
> > Żadna nie jest bardziej "true" czy "raw".
> > Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
> > (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej skopane,
niż w Pythonie 2)
>
> moze kolega podac przyklady i konkretne opinie bo inaczej taka dyskusja jest troche
pusta.. moge przecztac bo sie interesuje oststnie pare dni tym pythionem (poki mi nie
minie pewnia za jakies 2-3 dni)


Jeżeli idzie o Pythona jako takiego, to np. to:

>>> def f(x={})
... return x

>>> a = f()
>>> a
{}

>>> b = f()
>>> b
{}

>>> a['x'] = 5
>>> a
{'x':5}

>>> b
{'x':5}

Strasznie głupie.

Albo GIL.

Albo "piekło wersji", które zmusza do instalowania virtualenv.

Albo upośledzone lambda-wyrażenia.

Albo skopane zasięgi w "comprehensions" - na przykład, jeżeli napiszesz

powers = [lambda x: x**i for i in range(10)]

to jaką wartość będzie miało wyrażenie

powers[3](2)

?

I tak dalej.


Jeżeli zaś idzie o przejście z Pythona 2 do Pythona 3, to sądzę, że uspójnienie
instrukcji "print" z innymi funkcjami i wymaganie, żeby pisać

print(x)

zamiast

print x

było samo w sobie strasznie głupie.

do góry

W dniu środa, 15 kwietnia 2020 15:53:11 UTC+2 użytkownik g...@g...com napisał:
> W dniu środa, 15 kwietnia 2020 15:01:37 UTC+2 użytkownik fir napisał:
> > W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik g...@g...com
napisał:
> > > W dniu środa, 15 kwietnia 2020 13:45:24 UTC+2 użytkownik fir napisał:
> > > > W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik g...@g...com
napisał:
> > > > > W dniu środa, 15 kwietnia 2020 02:58:08 UTC+2 użytkownik fir napisał:
> > > > > > mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem
przyzwczajony do takich bledow)
> > > > > [...]
> > > > > > o co tu chodzi? jak to naprawic?
> > > > >
> > > > > Python 2.7 jest od tego roku oficjalnie niewspierany.
> > > > > Nie wiem, po co go używać, zwłaszcza do nowego projektu.
> > > > >
> > > > > Zdaje się, że w Pythonie 3.x natywne wsparcie dla Unicode'a w stringach
zostało poprawione.
> > > > >
> > > > > Możesz spróbować na wartości zwracanej przez recv wywołać decode('utf-8').
> > > > >
> > > > > Może pomoże.
> > > >
> > > > powszechna wiara ludzi ze nowsze wersje softu sa lepsze niz starsze jest
dosyc
> > > > glupia - roznie to bywa
> > >
> > > Zgadzam się. Jest głupia. Raczej takie uproszczenie "nowe=lepsze" się nie
sprawdza.
> > >
> > > Tyle że tutaj raczej chodzi o dostępność i o ekosystem, a nie o to, co jest
"lepsze".
> > >
> > > > ja mam jakas ciagate do starszych wersji i zauwazam ze cos w tym jest te
starsze sa czesto jakos bardziej true, raw, nie wiem jak to nazwac (sa tez zwykle
szybsze i prostsze)
> > >
> > > W przypadku Pythona zarówno wersja 2.x jak i 3.x jest raczej kiepska.
> > > Żadna nie jest bardziej "true" czy "raw".
> > > Wiele spośród zmian z Pythona 2 na Pythona 3 jest po prostu głupich.
> > > (Ale zdaje się, że akurat wsparcie dla stringów jest w Pythonie 3 mniej
skopane, niż w Pythonie 2)
> >
> > moze kolega podac przyklady i konkretne opinie bo inaczej taka dyskusja jest
troche pusta.. moge przecztac bo sie interesuje oststnie pare dni tym pythionem (poki
mi nie minie pewnia za jakies 2-3 dni)
>
>
> Jeżeli idzie o Pythona jako takiego, to np. to:
>
> >>> def f(x={})
> ... return x
>
> >>> a = f()
> >>> a
> {}
>
> >>> b = f()
> >>> b
> {}
>
> >>> a['x'] = 5
> >>> a
> {'x':5}
>
> >>> b
> {'x':5}
>
> Strasznie głupie.
>
> Albo GIL.
>
> Albo "piekło wersji", które zmusza do instalowania virtualenv.
>
> Albo upośledzone lambda-wyrażenia.
>
> Albo skopane zasięgi w "comprehensions" - na przykład, jeżeli napiszesz
>
> powers = [lambda x: x**i for i in range(10)]
>
> to jaką wartość będzie miało wyrażenie
>
> powers[3](2)
>
> ?
>
> I tak dalej.
>
>
> Jeżeli zaś idzie o przejście z Pythona 2 do Pythona 3, to sądzę, że uspójnienie
instrukcji "print" z innymi funkcjami i wymaganie, żeby pisać
>
> print(x)
>
> zamiast
>
> print x
>
> było samo w sobie strasznie głupie.

do tego wyzej jeszcze nie dotarlem atk ze nie wiem

co do ostatniego to samo zrobienie drugeigo bardzo podobnego jezyka ale
niekompatybilnego bylo straszna rzeczą

jeli robic drugi to mogli poczekaz az zbierze sie tak duzo niekompatybilnych zmien az
uczyni to inny jezyk .. i wtedy trzeba ciagnac oba (jakoz e pierwszy juz byl
popularny) ..
produkowanie dwu podobnych zakrawa na powazny (uciazliwy dla userow) blad

na szczescie nie zmienia to sytuacji ze bota sie koduje w tym naprawde swietnie

do góry

W dniu 2020-04-15 o 02:58, fir pisze:
> (...)>
> jesli jest to decode to moge zapisywac wpisy na dysk i moge je czytac ze slowniek i
wyswietlac na kanal - ale tylko poki nie zamkne bota i nie wczytam tego z dysku,
wtedy przy probie odczytania wpisu i wyslania go na kanal z tego leci blad (ascii
codect cant encode...)
>
> z kolei jak to decode wywale jest
> odwrotnie, po uruchomieniu boyta moge
> wysylac zapisane za poprzednim razem wpisy na kanal ale nie moge zapisac i odczytac
nowego, tj dokladniej w pliku tez sie zapisuje ale odczytanie go ze slownika i proba
poslania na kanal dale blad (ascii codec cant decode...)
>
> o co tu chodzi? jak to naprawic?

Zwróć uwagę, że w pythonie 2.x są dwa rodzaje stringów: ośmiobitowe
(bajtowe) i unikodowe, a z jednych na drugie przechodzisz przez encode()
i decode().
Jeśli nie zachowasz dyscypliny i nie wiesz jakie kodowania masz w
poszczególnych stringach bajtowych, to dzieją się ,,cuda" o których
piszesz wyżej.


przykład:

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500
64 bit (AMD64)] on win32

>>> import sys
>>> sys.stdin.encoding # sprawdzamy jakie jest domyślne kodowanie konsoli
'cp1250'

>>> s1 = "aą" # zwykły ośmiobitowy string, kodowanie cp1250
>>> s2 = u"aą" # string unicode, automatycznie przekodowany z konsoli
na unicode

>>> s1
'a\xb9'

>>> s2
u'a\u0105'

s1 nie ,,pamięta" swojego kodowania, można go dowolnie zinterpretować

>>> s1.decode(encoding="cp1250")
u'a\u0105'

>>> s1.decode(encoding="iso8859-2")
u'a\u0161'

>>> s1.decode(encoding="cp1256")
u'a\xb9'

s2 też można ,,spaprać", jeśli się go przepuści przez niekompatybilne
kodowania bajtowe, np.:

>>> s2.encode(encoding="utf8").decode(encoding="cp1250")
u'a\xc4\u2026'
>>> print s2.encode(encoding="utf8").decode(encoding="cp1250")
aÄ...


Rozwiązanie problemu jest takie jak w innych językach:
- znać kodowania wejściowe
- dekodować wejścia do jednego wspólnego dla całej aplikacji kodowania
(najczęściej unicode, ewentualnie utf-8) i na nim pracować
- znać kodowania wyjściowe i wyjścia kodować odpowiednio do wymagań

do góry

Postscriptum odnośnie:
> W dniu 2020-04-15 o 02:58, fir pisze: >>... leci blad (ascii codect cant encode...)
Widocznie robisz jakąś automatyczną konwersję, np zapisywanie stringa
unikodowego do pliku itp. jeśli nie podasz kodowania, to domyślne jest
"ascii" i każdy znak w tekście z kodem powyżej 127 wyrzuci błąd

>>> s2.encode()

Traceback (most recent call last):
File "<pyshell#26>", line 1, in <module>
s2.encode()
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0105' in
position 1: ordinal not in range(128)

trzeba podać kodowanie bajtowe do jakiego chcesz tekst przekształcić

>>> s2.encode(encoding="utf8")
'a\xc4\x85'

>>> s2.encode(encoding="iso8859-2")
'a\xb1'

albo zignorować błędy

>>> s2.encode(encoding="ascii", errors="ignore")
'a'

>>> s2.encode(encoding="ascii", errors="replace")
'a?'

do góry