🚀 go-pugleaf

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

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.

W dniu środa, 15 kwietnia 2020 12:54:16 UTC+2 użytkownik godek...@gmail.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

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 godek...@gmail.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)

W dniu środa, 15 kwietnia 2020 14:48:25 UTC+2 użytkownik godek...@gmail.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 godek...@gmail.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)

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 godek...@gmail.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 godek...@gmail.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.

W dniu środa, 15 kwietnia 2020 15:53:11 UTC+2 użytkownik godek...@gmail.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 godek...@gmail.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 godek...@gmail.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

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ń

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?'

> I tak dalej. 

Mój ulubieniec:

>>> x = 42
>>> def foo():
...     x = x
... 
>>> foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
UnboundLocalError: local variable 'x' referenced before assignment
>>> 

Nie dość, że głupie, to nawet niezgodne z dokumentacją. Od zawsze.

-- 
Maciej Sobczak * http://www.inspirel.com