Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Stefan Schwarzer Newsgroups: de.comp.lang.python Subject: =?utf-8?q?=5BPython-de=5D_Re=3A_konstante_Lists=2C_Dictionaries?= Date: Fri, 22 Dec 2023 21:25:57 +0100 Lines: 69 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.uni-berlin.de /lnsUtlcwkmeZy12EqePZgYUefLEc96MHYFWCaoU5oYA== Cancel-Lock: sha1:jO4KAFCtz+vJTMIQD1uCQVYCoDI= sha256:ZjWxrMAKKYWLgBun3/Her8xrtKmbcmCw4uvLf2LF1ak= Authentication-Results: mail.python.org; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral User-Agent: Mozilla Thunderbird Content-Language: en-US, de-DE In-Reply-To: X-Provags-ID: V03:K1:S1Eo0VRSgIHEi3GUj2eIBLllJb+Yq5gCsXkzfTUMjrKbSGNzdOH 3jgsV1mxXVwVIeq0u6/1ECdosQluJDVQMTWFaE4k81N7w/A+CiiEvB/uf4aqj9bjZykbM46 ri8n5UkRETybum4MixFvoKIE39RQxPYHbHKq97umKY5j+wBRKriGMMiSPjWLIO09AtMV6Fz oxqrYOFLeigX6KM0XYQfw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:TexDTrdOpFg=;fYx/k1R1pIP2KnghKLWadHENj6g I7hXTE8fEpTOSJ8L89wlI3xhIHSQNt//1Y2k3BMHXKvlwo4LasNIVuRbOqKTrBERFCB78c9by 1zhDldWVlMHCQ/M8DFWZoJo5vuoijjnCPIdP7+KLWIw8rr6GwMr+SM7aEocR4BGcxNzEQGi4s oK7qQCkjNPrUdXV4WpxEaiDBX13DRdmIqrDL25yAV6BXatF8q7p0ytomy+0pgtMLj0aaWR7EM Kbfda+dc9plarHHUScRhNb5DYbOQWL+sOQgyzqd5CGQdz+qkooq+JT/8Lcz/hg3q+f53uxDfE GFNqhcosyqTlNc30QdmJWIHahxY700zVlskenK2Nx/oHd6fvGb/4w/mP5ms/pEfYCEhL1+SDm HzXCU1KN002wny18g/LVa5UF7Sv11pXXX9794fDtm/Yuyy7v+vO8clE/juPqIU2fBqy7MP5kR roXAilBRclCcfacJRr0psHBLA6OmP2tUsiu5+hBCxkOQOljR5VWgdhNHhJChCRBXX4TvQLCPY ZpwMXxuPucG7l/F+c9QiqeJiADA5ifWisTcA4+IeT9eay6glVq8upZ+4Nn1hx/+78waewRQPA F5/Iz+ySM5I3LBklD0a7Q/EoL42o96R+dB4Y+aATCVM4McU6YUsdbZ+MkrUl8YJ7yxqjhFLL1 b+LCLDFltEMHazgIIqRNiHfNCSMwnGSU8AZXMWRrZReJ9WACxIl8DUl/2s+s83tgxunxu/7+s rK5e6VmHzl+5/aGWcS0hl5JsXDgrd/IXnFnechJuqzIfoCtZrBA4Xm465lYuyaUimfgN2Zrmq ejqRFhnaOD3mi71DM7/wdO5E9ly3wIa0oKRxBqHGH4tGx0wFFlHGesK+2ETegVmoOh3DK1kZp xhCkbgIV29revcw== Message-ID-Hash: QSOATKNVS65NVWQGXWO55BCG576FCKAB X-Message-ID-Hash: QSOATKNVS65NVWQGXWO55BCG576FCKAB X-MailFrom: sschwarzer@sschwarzer.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-python-de.python.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10b1 Precedence: list List-Id: Die Deutsche Python Mailingliste Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Xref: csiph.com de.comp.lang.python:6014 On 2023-12-22 20:32, Markus Schaaf wrote: > habe heute ewig nach einem "unmöglichen" Fehler gesucht, weil ich > nicht gemerkt hatte, dass ein Dictionary von verschiedenen > Coroutinen modifiziert wird. Vor sowas schützt Python in der Tat schlecht. > In typisierten Sprachen würde man > der Coroutine eine konstante Referenz übergeben. Python ist auch "typisiert", aber das Typ-System gibt es nicht her, Änderungen zu kontrollieren. ;-) > Gibt's in Python > Methoden, sich vor solchen Fehlern zu schützen, ohne eine tiefe > Kopie anzulegen? (Oder vielleicht ist das gar nicht so schlimm?) Ein paar bunt gemischte spontane Gedanken dazu ... :-) - Ob tiefe Kopien ein Problem für dein Programm und die darin verarbeiteten Daten sind, musst du ausprobieren. Bei nicht zu riesigen Datenmengen und häufigen Kopien kann es gutgehen. - Versuch, im Design die Konstellation, dass ein Objekt von verschiedenen Stellen geändert wird, von vornherein möglichst zu vermeiden. Ok, das ist zugegebenermaßen sehr schwammig und es hängt von deinem Programm ab, ob sich das gut umsetzen lässt. - Ich versuche, in-place-Änderungen möglichst zu vermeiden und stattdessen modifizierte Objekte zurückzugeben. Sowas ist eher in der Funktionalen Programmierung üblich, klappt aber auch oft in Python einigermaßen erträglich. Je nachdem, was du für Daten hast und wie dein Programmfluss ist, kann das aber auch darauf hinauslaufen, dass du viele tiefe Kopien erzeugst, was ein Problem sein _kann_ (siehe oben). - Recherchiere zu sogenannten persistenten Datenstrukturen. Die funktionieren so, dass bei einer Änderung ein neues Objekt mit den Änderungen erzeugt wird und das ursprüngliche Objekt unverändert bleibt. Anders als bei Python-Listen oder -Dictionaries hängt die Zeit für ein solches "funktionales Update" nicht (wesentlich) von der Größe der Datenstruktur ab. Ich habe bei einer Suche zum Beispiel https://github.com/tobgu/pyrsistent gefunden, kann aber nicht einschätzen, inwieweit das in dein Design passt. Im Zweifelsfall würde ich erst mal versuchen, das Problem mit "Python-Standard-Designs" zu lösen. In dem Zusammenhang würde mich interessieren, wer von euch Erfahrungen mit solchen Datenstrukturen/Bibliotheken in Python hat und wie gut das für euch funktioniert hat. - Python hat, anders als zum Beispiel Rust, kein explizites Ownership-System, aber du kannst dir trotzdem beim Designen überlegen, welches Objekt der Owner eines bestimmten Objekts sein soll. Ich denke, um konkretere Ratschläge zu bekommen, müsstest du deinen Code zeigen beziehungsweise die "konkurrierenden" Code-Teile genauer beschreiben. Davon abgesehen interessiert mich, wie andere Entwickler:innen mit dieser Problematik umgehen. Was habt ihr für Ansätze ausprobiert und was waren eure Erfahrungen? Viele Grüße Stefan