Discussion:
kolejne pytanie z pythona
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
fir
2020-04-15 00:58:06 UTC
Permalink
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?
fir
2020-04-15 01:36:35 UTC
Permalink
Post by fir
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
g***@gmail.com
2020-04-15 10:54:14 UTC
Permalink
Post by fir
mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do takich bledow)
[...]
Post by fir
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.
fir
2020-04-15 11:45:23 UTC
Permalink
Post by g***@gmail.com
Post by fir
mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do takich bledow)
[...]
Post by fir
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
g***@gmail.com
2020-04-15 12:48:23 UTC
Permalink
Post by fir
Post by g***@gmail.com
Post by fir
mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do takich bledow)
[...]
Post by fir
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".
Post by fir
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)
fir
2020-04-15 13:01:34 UTC
Permalink
Post by g***@gmail.com
Post by fir
Post by g***@gmail.com
Post by fir
mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do takich bledow)
[...]
Post by fir
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".
Post by fir
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)
g***@gmail.com
2020-04-15 13:53:09 UTC
Permalink
Post by fir
Post by g***@gmail.com
Post by fir
Post by g***@gmail.com
Post by fir
mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do takich bledow)
[...]
Post by fir
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".
Post by fir
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)
Post by g***@gmail.com
Post by fir
def f(x={})
... return x
Post by fir
Post by g***@gmail.com
Post by fir
a = f()
a
{}
Post by fir
Post by g***@gmail.com
Post by fir
b = f()
b
{}
Post by fir
Post by g***@gmail.com
Post by fir
a['x'] = 5
a
{'x':5}
Post by fir
Post by g***@gmail.com
Post by fir
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.
fir
2020-04-15 15:01:32 UTC
Permalink
Post by g***@gmail.com
Post by fir
Post by g***@gmail.com
Post by fir
Post by g***@gmail.com
Post by fir
mam dziwny problem (moze nie taki dziwny w sumie ale nie jestem przyzwczajony do takich bledow)
[...]
Post by fir
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".
Post by fir
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)
Post by g***@gmail.com
Post by fir
def f(x={})
... return x
Post by fir
Post by g***@gmail.com
Post by fir
a = f()
a
{}
Post by fir
Post by g***@gmail.com
Post by fir
b = f()
b
{}
Post by fir
Post by g***@gmail.com
Post by fir
a['x'] = 5
a
{'x':5}
Post by fir
Post by g***@gmail.com
Post by fir
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
Maciej Sobczak
2020-04-17 19:04:31 UTC
Permalink
Post by g***@gmail.com
I tak dalej.
x = 42
... x = x
...
Post by g***@gmail.com
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
Piotr Chamera
2020-04-15 19:14:29 UTC
Permalink
(...)>
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
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ń
Piotr Chamera
2020-04-15 19:27:41 UTC
Permalink
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?'
Kontynuuj czytanie narkive:
Loading...