[Python-de] Re: Sprachfeatures und so (war: Modul von woanders laden)

Matthias Urlichs smurf at noris.de
Sat Mar 9 17:36:36 EST 2002


Hi,

clemensF:
> dieses beispiel ist aber nicht so schoen.  aber "...solche praktiken zogen
> sich durch den ganzen code..." lassen auf mehr hoffen.  also, raus mit den
> beispielen!

Hmm. Ich erinner mich an die Methode, rekursive Prozeduraufrufe zu
schreiben.

In COBOL ist das verboten, weil viele Rechner einen Unterprogrammaufruf
derart implementiert haben, dass am Ende der aufgerufenen Routine das dort
gespeicherte NOP durch einen Sprung auf die Fortsetzungsadresse ersetzt
und nach dem Rücksprung restauriert wird.

Was macht der clevere COBOL-Programmierer also: Er macht Folgendes
(an COBOL-Syntax kann ich mich in keinster Weise mehr erinner):

RekursiveProzedur:
	Index=0
RekProcInnen:
	...
	if rufe_mich_selber:
		Setze_Index_N+1_Variablen
		Index+=1
		GOSUB RekProcInnen
		Index-=1
	GOTO RekProcEnde
RekProcEnde:
	Index=0

Setze_Index_0_Variablen
GOSUB RekursiveProzedur THRU RekProcEnde

Eine sinnvolle Übersetzung würde natürlich auf einen einfachen
Prozeduraufruf mit den Variablen als Argument rauslaufen.

Man kann natürlich auch um einiges dümmer vorgehen, will man dies nach C
übersetzen.  :-/


Nun ist dieses Beispiel ja, um zur Python-Relevanz zurückzukommen, ein
relativ einfaches Muster, was nur dadurch kompliziert wird dass ein
Sprach-Feature, das COBOL halt nicht hat, zur Umgehung eines Problems mit
Bordmitteln nachgebaut und bei der Rückübersetzung in eine mächtigere
Sprache nicht wieder korrekt in "normalen" Code transformiert wurde, und
das noch dazu relativ lokalisiert auftritt.

Nun nehme man ein komplexeres Beispiel, wie zB den Grundgedanken "wir
ersetzen prozeduralen SQL-Zugriff und die Übergabe von Integer-PRIMARY
KEY-Werten durch Objekte mit Gedächtnis". Also: statt
	db.DoSQL("UPDATE kunde SET letzte_rechnung="+SQLDATE(2002,03,01)+" WHERE ID=kunde_id"
was massiv fehlerträchtig ist wenn man anfängt drüber nachzudenken, soll
einfach nur
	kunde.letzte_rechnung=mx.Date(2001,03,01)
dastehen.

Bitte die Tatsache, dass SQL Transaktionen hat, die auch mal fehlschlagen
können, und trotzdem lokales Cachen diverser Werte essenziell ist, nicht
vergessen. ;-)

... vor dem Problem steh ich gerade, und finde es ziemlich nervig, dass
ich dafür anscheinend einen ZODB-Server mit nativer Datenbankunter-
stützung programmieren muss... scheint es ja noch nicht zu geben.

Ohne SQL gehts leider nicht.  :-/
-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/



More information about the Python-de mailing list