Python bytearray to string

[Oriesok789]

Dobry den.

V pytone mam nieco taketo

Kód [Vybrat] Rozbalit

import snap7

plc = snap7.client.Client()

plc.connect('192.168.0.1', 0, 1)
print("CON STATUS: ", plc.get_connected());

reading = plc.db_read(1, 4, 20)

reading.decode("utf-8", errors="replace")

print (reading)

plc.disconnect()

Vracia mi to ale hodnotu
bytearray(b'String no. 1\x00\x00\x00\x00\x00\x00\x00\x00')
skusal som to osetrit cez decode tak aby to vracalo len "cisty text" teda String no. 1 ale bez uspechu. Vedel by niekto poradit?

[Reklama]

[gill]

Decode vraci decodovanou hodnotu, ale nemeni puvodni hodnotu. V pythonu vetsinou plati konvence, ze funkce vracejici hodnotu nic nemeni. Funkce se side efekty vraci None.

[Oriesok789]

gill ako by som mal teda postupovat tak aby to bolo koretne?

[Oriesok789]

prepacte som to netoto na prvy krat

reading = reading.decode("utf-8") takto je to ok.

[Vít Šesták (v6ak)]

Já bych radil se vyvarovat tomuto přepisování proměnných. Samozřejmě, řádek reading = reading.decode("utf-8") bude fungovat, ale znesnadňuje to čtení – najednou v té proměnné mám jinou hodnotu, dokonce i jiný typ. Radši bych vytvořil novou proměnnou a napsal něco jako reading = reading_bytes.decode("utf-8").

(Nechávám stranou, jestli ,,reading" je vhodný název proměnné.)

[Reklama]

[SB]

Toto je typické uvažování z typovaných jazyků - v nich není mezivýsledek v extra proměnné ani tak kvůli přehlednosti jako kvůli typu, string prostě nejde strčit do byte array, kdežto v netypovaném jazyku je to buřt.
Vzhledem k tomu, že se proměnná jmenuje "reading" (i když je to zde debilní název), i po konverzích jsou v ní pořád data ze čtení (i když v jiném formátu) - z tohoto pohledu je vše v pořádku.
Budu-li dělat 20 konverzí za sebou, mám to nechat v jedné proměnné, nebo udělat 20 proměnných? Závěr: Je to čistě věcí osobního uvážení, jak přesně chci mít obsah pojmenovaný, případně zda vůbec s jednotlivými mezivýsledky budu něco dělat.

[kate]

Toto je typické uvažování z typovaných jazyků

Rozhodně bych tu praktiku nevázala jen na dynamické jazyky. Třeba Rust je strong typed jazyk, ve kterém je variable shadowing nejen povolený a běžně používaný, ale v některých případech i vyloženě žádoucí (shadowing proměnné sama sebou se používá na zrušení mutability)

[nula]

Toto je typické uvažování z typovaných jazyků - v nich není mezivýsledek v extra proměnné ani tak kvůli přehlednosti jako kvůli typu, string prostě nejde strčit do byte array, kdežto v netypovaném jazyku je to buřt.
Vzhledem k tomu, že se proměnná jmenuje "reading" (i když je to zde debilní název), i po konverzích jsou v ní pořád data ze čtení (i když v jiném formátu) - z tohoto pohledu je vše v pořádku.
Budu-li dělat 20 konverzí za sebou, mám to nechat v jedné proměnné, nebo udělat 20 proměnných? Závěr: Je to čistě věcí osobního uvážení, jak přesně chci mít obsah pojmenovaný, případně zda vůbec s jednotlivými mezivýsledky budu něco dělat.

Jen detaily: Jazyk python je typovany jazyk. Akorat ne staticky typovany. A za druhe ..vlastne to co psala kate, to co pisete neni vzdy nutnost ani ve staticky typovanych jazycich.

[qelurg]

Já bych radil se vyvarovat tomuto přepisování proměnných. Samozřejmě, řádek reading = reading.decode("utf-8") bude fungovat, ale znesnadňuje to čtení – najednou v té proměnné mám jinou hodnotu, dokonce i jiný typ. Radši bych vytvořil novou proměnnou a napsal něco jako reading = reading_bytes.decode("utf-8").

(Nechávám stranou, jestli ,,reading" je vhodný název proměnné.)

Naopak, nepřehledné je mít milion různých proměnných v kterých jsou stejná data a která nepotřebujeme současně. Jedná se pořád o jedny a ty samá data, je správné mít pro ně stále stejný název. Potřeba měnit proměnné je zlozvyk ze staticky typovaných jazyků, kde je to technická nutnost, je to důsledek omezení těchto nižších jazyků, které nemají žádný přínos.

[kate]

kde je to technická nutnost, je to důsledek omezení těchto nižších jazyků, které nemají žádný přínos.

Technická nutnost fakt ne. Asi to usnadňuje psaní kompileru (nemám zkušenost), ale jinak je to fakt jen na libovůli tvůrce jazyka, se statickou typovostí to nemá nic moc společného. Viz třeba výše zmíněný Rust, tvrdit že je to dynamicky typovaný jazyk by bylo slušné šílenství ;-)

[gill]

kde je to technická nutnost, je to důsledek omezení těchto nižších jazyků, které nemají žádný přínos.

Technická nutnost fakt ne. Asi to usnadňuje psaní kompileru (nemám zkušenost), ale jinak je to fakt jen na libovůli tvůrce jazyka, se statickou typovostí to nemá nic moc společného. Viz třeba výše zmíněný Rust, tvrdit že je to dynamicky typovaný jazyk by bylo slušné šílenství ;-)

resilo se tu prirazeni hodnoty ruznych typu do jedne promenne.

[kate]

resilo se tu prirazeni hodnoty ruznych typu do jedne promenne.

Přičemž ,,jednou proměnnou" byl nejspíš myšlen název proměnné, nebyl?

Kód [Vybrat] Rozbalit

IPython 6.4.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: a = 1

In [2]: id(a)
Out[2]: 140418482099424

In [3]: a = "mrkev"

In [4]: id(a)
Out[4]: 140418212429360


Opravdu je v obou případech a stejná proměnná, navzdory odlišnému ID? Jak se to liší od téhle konstukce v Rustu, kterou třeba C++ neumožňuje?

Kód [Vybrat] Rozbalit


let i = 1;
let i = "mrkev";


[gill]

Opravdu je v obou případech a stejná proměnná, navzdory odlišnému ID? Jak se to liší od téhle konstukce v Rustu, kterou třeba C++ neumožňuje?

Kód [Vybrat] Rozbalit


let i = 1;
let i = "mrkev";


nevedel jsem, ze neco takoveho jde. omlouvam se za nedorozumneni.

[kate]

nevedel jsem, ze neco takoveho jde. omlouvam se za nedorozumneni.

Jak jsem psala výš, dokonce je to v Rustu často používaný postup A silná statická typovost jazyka shadowing navíc dost zpřehledňuje, vždy je naprosto jasné jaký datový typ se pod tím identifikátorem aktuálně skrývá.

[SB]

Rozhodně bych tu praktiku nevázala jen na dynamické jazyky. Třeba Rust je strong typed jazyk, ve kterém je variable shadowing nejen povolený a běžně používaný, ale v některých případech i vyloženě žádoucí (shadowing proměnné sama sebou se používá na zrušení mutability)

1. Kolik jazyků to má?
2. Není to další rovnák na ohýbák?