Hallo,

habe heute ewig nach einem "unmöglichen" Fehler gesucht, weil ich
nicht gemerkt hatte, dass ein Dictionary von verschiedenen
Coroutinen modifiziert wird. In typisierten Sprachen würde man
der Coroutine eine konstante Referenz übergeben. 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?)

MfG

On 2023-12-22 19:32, Markus Schaaf <mschaaf@elaboris.de> wrote:
> habe heute ewig nach einem "unmöglichen" Fehler gesucht, weil ich
> nicht gemerkt hatte, dass ein Dictionary von verschiedenen
> Coroutinen modifiziert wird. In typisierten Sprachen würde man
> der Coroutine eine konstante Referenz übergeben.

"In typisierten Sprachen" scheint mir unzulässig allgemein zu sein.
Wirlich in allen typisierten Sprachen? Und was ist überhaupt eine
"konstante Referenz"? Immutable soll ja wohl nicht die Referenz sein,
sondern das, worauf die Referenz zeigt.

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

Speziell für dict gibt es einen PEP für frozendict und offenbar auch
eine Referenzimplementation auf PyPI.

Wenn Dein Objekt nicht allgemein immutable sein soll, sondern nur für
manche Routinen, könntest Du denen ein Proxy-Objekt übergeben, das nur
lesende Zugriffe auf das Originalobjekt durchreicht (Hmm, das müsste man
eigentlich ziemlich generisch schreiben können),

hp

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

Am 22.12.23 um 21:01 schrieb Peter J. Holzer:

> Speziell für dict gibt es einen PEP für frozendict und offenbar auch
> eine Referenzimplementation auf PyPI.
>
> Wenn Dein Objekt nicht allgemein immutable sein soll, sondern nur für
> manche Routinen, könntest Du denen ein Proxy-Objekt übergeben, das nur
> lesende Zugriffe auf das Originalobjekt durchreicht (Hmm, das müsste man
> eigentlich ziemlich generisch schreiben können),

Danke. Sind beides gute Hinweise.

Markus Schaaf <mschaaf@elaboris.de> writes:
>nicht gemerkt hatte, dass ein Dictionary von verschiedenen
>Coroutinen modifiziert wird. In typisierten Sprachen würde man
>der Coroutine eine konstante Referenz übergeben. 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?)

Das folgende Program zeigt, wie man in Python ein "konstantes
Wörterbuch" c definieren könnte, das die Daten mit einem
nicht-konstanten Wörterbuch d teilt. Es ist aber nur als eine
Ideenskizze zu verstehen. Vor einem etwaigen Einsatz in der
Praxis sind je nach Bedarf vermutlich Anpassungen vorzunehmen.
(Für Listen sollte das auch ähnlich gehen.)

main.py

import collections

class dictionary( collections.UserDict ):
pass

class const_dict( dictionary ):
def __init__( self, other ):
self.data = other.data
def __setitem__( self, key, item ):
raise NotImplementedError

d = dictionary()
d[ 1 ]= 2
print( d )
c = const_dict( d )
print( c )
c[ 2 ]= 3

stdout

{1: 2}
{1: 2}
Traceback (most recent call last):
File "main.py", line 17, in <module>
c[ 2 ]= 3
File "main.py", line 10, in __setitem__
raise NotImplementedError
NotImplementedError

Am 22.12.23 um 21:25 schrieb Stefan Schwarzer:

> - 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.

Das mache ich ja. Ich nutze sonst viel C++. Und da ist es
beliebt, sich "kleine" Fehler vom Compiler melden zu lassen. Das
ist kein Fetisch, sondern die Einsicht, dass Menschen dumme
kleine Fehler machen.

> - Ich versuche, in-place-Änderungen möglichst zu vermeiden und
> stattdessen modifizierte Objekte zurückzugeben.

Das scheint mir die richtige Vorgehensweise für Python zu sein.

> Ich denke, um konkretere Ratschläge zu bekommen, müsstest du
> deinen Code zeigen beziehungsweise die "konkurrierenden"
> Code-Teile genauer beschreiben.

Es gibt da kein existentielles Problem. Ich habe den Algorithmus
einfach so geändert, dass ich das "globale" Dictionary nicht
modifiziere. Das Problem ist dadurch entstanden, dass ich
Änderungen an einer Coroutine vorgenommen habe, ohne zu erkennen,
dass ein Funktionsparameter geteilt wird. Sah ja lokal aus.

MfG

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>class dictionary( collections.UserDict ):

Oben habe ich versehentlich gegen eine Empfehlung aus PEP 8
verstoßen.

|Class names should normally use the CapWords convention.
PEP 8

Ich hätte die Klasse also "Dictionary" (usw.) nennen sollen!

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>import collections
>class dictionary( collections.UserDict ):
> pass
>class const_dict( dictionary ):
> def __init__( self, other ):
> self.data = other.data
> def __setitem__( self, key, item ):
> raise NotImplementedError

Allerdings wäre danach

issubclass( const_dict, collections.abc.MutableMapping )

wahr (/Mutable/!). Dies mag in der hier beschriebenen Anwendung
kein Problem sein; aber um dies zu verhindern, könnte man
"const_dict" auf collections.abc.Mapping bauen.

ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>Das folgende Program zeigt, wie man in Python ein "konstantes
>Wörterbuch" c definieren könnte, das die Daten mit einem
....
>def __setitem__( self, key, item ):
> raise NotImplementedError

Man nennt solche Objekte in Python auch "frozen".

Verwendet man bei einer dataclass "frozen=True" so erhält man
entsprechend auch eine "__setattr__"-Methode mit einem "raise".

ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>Allerdings wäre danach
>issubclass( const_dict, collections.abc.MutableMapping )
>wahr (/Mutable/!). Dies mag in der hier beschriebenen Anwendung
>kein Problem sein; aber um dies zu verhindern, könnte man
>"const_dict" auf collections.abc.Mapping bauen.

Hier nun eine korrigierte Version:

import collections.abc

class ImmutableMap( collections.abc.Mapping ):

def __init__( self, *args, **kwargs ):
self._data = dict( *args, **kwargs )

def __len__( self ):
return len( self._data )

def __getitem__( self, key ):
return self._data[ key ]

def __iter__( self ):
return iter( self._data )

def __contains__( self, key ):
return key in self._data

def get( self, key, default=None ):
return self._data.get( key, default )

def __str__( self ):
return str( self._data )

print( issubclass( ImmutableMap, collections.abc.MutableMapping ))
print( issubclass( ImmutableMap, collections.abc.Mapping ))

d = dict()
d[ 1 ]= 2
print( d )

c = ImmutableMap( d )
print( c )
c[ 2 ]= 3

Ausgabe:

False
True
{1: 2}
{1: 2}
Traceback (most recent call last):
File "Main.py", line 35, in <module>
c[ 2 ]= 3
TypeError: 'ImmutableMap' object does not support item assignment