Python WTF! ezt meg igy hogy?

Szkriptek: Python, Perl, Bash, ...

Biztos en vagyok a hulye, de ezt nem ertem, hogy itt mi tortenik a dict-el a func hivasok kozott:

def parse(params,d={}):
    for p in params.split(";"):
        k,v=p.split("=",1)
        d[k]=v
    return d

x=parse("a=1;b=2")
print(x)
y=parse("c=3")
print(y)
z=parse("d=4;e=5")
print(z)

# ./wtf.py

{'a': '1', 'b': '2'}
{'a': '1', 'b': '2', 'c': '3'}
{'a': '1', 'b': '2', 'c': '3', 'd': '4', 'e': '5'}

ugye itt azt varnam, hogy mindig csak az aktualis parse() hivas eredmenye keruljon bele a returned dict-be, de a korabbiak hogy kerulnek oda pl. a z-be az a:1 ?

igen, tudom hogy ha a d={} nem a parameterekbe lenen hanem a def utani sorban akkor mukodik, de az volt a cel, hogy opcionalisan meg lehessen adni egy mar letezo dict-et, hogy abba parsoljon bele.

  • 1540 megtekintés

( dragi v | 2023. 07. 11., k – 15:44 )

Mert list és dict paraméterben mem referencia  lesz, és ha már létezik akkor ugyan az lesz.

koszi, legalabbis elmagyaraztak tobbfele megkozelitesbol, hogy ez miert van igy, meg hogy ez mekkora faszsag masok szeirnt is :)

szoval a gyakorlatban ez igy viselkedik, es igy mar ertheto:

default_d={}

def parse(params,d=default_d):
   ...

meg hogy ez mekkora faszsag masok szeirnt is :)

Nem állítom, hogy nem fájdalmas, de őszintén szólva így legalább konzisztens a referencia kezelés a nyelvben, inkább ez, mint a mindenféle kivételek gányolása. Fel szoktuk tenni egyébként interjún ezt a kérdést, a legtöbben rájönnek, hogy mi hibázik, elég sokan arra is, hogy miért, érdekes módon megoldani egész sokan nem a gyak minden production codeban tele levő if p is None: formával próbálják. :)

Egyébként ez elég c kód így, szerintem tisztább, (de mindenképp pythonikusabb, bár az nem annyira szinonima mindig :D) ha a parse azt csinálja, amit a neve mond, ad egy felparsolt dictet, aztán ha a hívó szeretné ezt másokkal összeönteni, akkor mondhatja, hogy mydict.update(parse(params)). Ha háklis vagy az erőforrásokra, akkor a d[k]=v helyett mondhatod, hogy "yield k,v".

Ja, és ez nyilván alkalmazás függő, de ilyenre tényleg nincs valami értelmes serializált formátum, hogy ne kelljen splitekkel baszakodni?

tudom, eddig azt hasznaltam. de egyreszt tetu lassu (foleg pypy-vel, bar azt most talan megfixeltek), meg bugos is (van egy csomo levelem amin az elszall - persze nyilvan az email is hibas valamennyire, de lehetne toleransabb a parseruk).

csak osszehasonlitaskent, az en parserem 0m7.724s (pypy-vel 0m6.703s) alatt daralt le 95 ezer levelet, az email lib ugyanezt 4m10.829s (pypy-vel 2m58.758s) alatt...

Sebességét annyira nem néztem (nem ott volt nekünk a bottlenekc), ajánlani azért mertem, mert azért valamennyire megtekertük mindenféle érdekesebb levéllel, és csak nagyon fosott spam jellegűeken esett el néha, eleve azért kezdtük el nézni, mert a java minden szarra besírt.

De jó tudni, hogy valójában nem az igazi. köszi.

a pypy ticket fini :)

hat 100k levelbol volt ugy 7 amin elhasalt szoval annyira azert valoban nem rossz, de akkor is. foleg, hogy en spamszurot fejlesztek, igy foleg spam leveleket kell parsolni...

meg van sok olyan level, amin nem szall el, de megse jol parsolja, kimaradnak mime partok vagy rosszul irja a content typeot...

> mime part elhagyás

pedig meglepoen sok emailben hianyzik a vegerol az end-boundary, ami a levelezoprogramokat lathatoan nem zavarja, de az email lib tudomast sem vesz emiatt az utolso partrol :(

> aki nem tudja szabványosan összerakni a levelét, mehetne a faszba

en egyetertenek, de ahogy altalaban, a spamek (nyilvan nem mind, de eleg sok) jobban betartjak az RFC-ket mint a nem-spam levelezes... kulonos tekintettel a PHPistikek altal osszekokanyolt webaruhazak rendeles-visszaigazolo meg szamla leveleire, de lattam mar valami nyugateuropai allami intezetbol is olyan levelet amit minden alkalommal megfogott a szurom mert nem birta parsolni. de amig az outlook es/vagy thunderbird megjeleniti, addig muszaj nekem is valahogy belelatni...

pedig meglepoen sok emailben hianyzik a vegerol az end-boundary, ami a levelezoprogramokat lathatoan nem zavarja, de az email lib tudomast sem vesz emiatt az utolso partrol :(

Hú, erről rémlik valami, megpróbálom majd feltúrni. 

pedig meglepoen sok emailben hianyzik a vegerol az end-boundary, ami a levelezoprogramokat lathatoan nem zavarja, de az email lib tudomast sem vesz emiatt az utolso partrol :(

De jó, hogy nem én fejlesztek ilyesmit :D Írtam már ilyen-olyan parsert életemben, de email nem szeretnék, az átlagosnál nagyobb szopásnak látszik.

( zwei | 2023. 07. 11., k – 15:44 )

Szerkesztve: 2023. 07. 11., k – 15:56

.

( zdesigner | 2023. 07. 11., k – 15:55 )

A d default értéke mutable. Egy rendes IDE nyavajogna miatta rögtön. :)

( Nyosigomboc v | 2023. 07. 11., k – 16:05 )

Klasszikus hiba, pedig elegge logikus.

Szokasos javitasa: d=None default erteknek, aztan if d is None: d={}

A strange game. The only winning move is not to play. How about a nice game of chess?

nem vagom a lex/yacc szintaxist (vagy 20 eve nem is talalkoztam ilyennel sehol, azt hittem mar kihalt :))

inkabb valami cseles regexp lesz a megoldas, vagy marad a karakterenkenti vegigiteralas, keves ilyen string van es nem is hosszuak (atlag 40-50 karakter), ki lehet birni, nem ezen fog mulni. de lehet erre hasznalom az email lib sajatjat, majd meglatom.

( Caro | 2023. 07. 11., k – 19:01 )

Jók ezek a magas szintű nyelvek, de nagyon kell őket ismerni.

Nemrég azzal szívtam php-ban, hogy:

if (!query->execute()) {...}

2x került be az SQL-be amit akartam. Hogy ezt mi a halálért értékelte ki kétszer, csak tippem van, de amint átírtam erre, működött:

$query_result=query->execute();

if (!$query_result) {...}

Ó, mennyi ilyen kóddal találkoztam a régi szép időkben.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

> nagyon gáz bemenő paramétert módosítani (és vissza is adni).

Kivéve persze, ha a kolléga azért nem követi a 'pure function' modellt ebben az esetben, mert nem is akarja.

(Tudni kell, hogy nagyon sokféle modell van a programozásban, ezek közül számos olyan is van, amik nem használhatók egyszerre.)