[linux-l] typdynamische Sprachfeatures

[Axel Weiß]

Volker Grabsch schrieb:
> 	p = Person()
> 	p.__dict__['name'] = "Hans" # Das geht!
> 	hello(p)
>
> Nun funktioniert alles. Selbst wenn der Compiler also feststellen
> könnte, dass "hello" das Attribut "name" von seinem Parameter
> verlangt, und dass "Person" dieses Attribut nicht bieten kann, müsste
> er den String-Parameter 'name' noch verstehen, und wenn man diesen zur
> Laufzeit erst zusammenbaut, hat der Compiler keine Chance mehr.

Ja, Python hat ein paar gruselige Features. Interessant finde ich hier, 
dass im Zusammenhang mit Python immer OO-Vokabular benutzt wird 
(Attribute, Methoden, usw.), Python also offensichtlich eine 
objektorientierte Sprache ist. Zur Stärke der objektorientierten 
Sprachen gehört jedoch gerade, dass für solche Konstrukte auch saubere 
Varianten existieren. Und das bedeutet, dass ich es eigentlich verbieten 
will, dass man einem Objekt eine neue Methode oder ein neues Attribut 
andichtet.

Ich kenne bis heute kein Beispiel, was sich nicht mit sauberen 
OO-Konzepten hinschreiben lässt, dafür aber mit Python's dynamischen 
Features. Ich lasse mich aber gerne vom Gegenteil überzeugen...

> Macht man hingegen das hier:
>
> 	p = Person()
> 	p.name = "Hans" # Das geht!
> 	hello(p)

Meiner Meinung nach verleitet die (ernsthafte) Anwendung solcher 
Konstrukte zur Herstellung von unübersichtlichem, wenn nicht sogar 
nichtvorhersehbarem Code, ala 'self-modifying code', der in den 80er 
Jahren ungeahnte Möglichkeiten verhieß. Wie gesagt, das geht auch 
sauber. Wenn ich a priori weiß, dass ich Person-Objekte an die Funktion 
hello übergeben will und hello auf ein Attribut name zugreift (mehr weiß 
man über die Argumente von hello nicht?), dann kann ich das etwa so 
hinschreiben:

	class Helloable:
		String name;

	def hello (Helloable h):
		print "Hello ", h.name, "!"

	class Person: inherits Helloable
		#pass

und alles ist wohlgeordnet, sprich: der Compiler kann die Typen prüfen. 
Und wenn ich nicht a priori weiß, dass ich Person-Objekte an die 
Funktion hello übergeben will, dann sollte ich das lassen!

> 1) gibt es ein Compiler-Projekt für Python, wo eben diese Sorte von
>    Vorhersagen irgendwie ermöglicht werden. Will man den nutzen, darf
>    man natürlich nicht mehr die ganz krassen Python-Features nutzen,
>    aber du braucht man eh selten. Den Namen des Projektes weiß ich
>    leider nicht mehr.

Python ist nicht mächtiger als C++, bezogen auf die zu lösenden Probleme. 
Ein Python-Compiler wird die Sprache auf die Konstrukte reduzieren, die 
eine Typüberprüfung zur Compilezeit erlauben - oder ganz auf statische 
Typprüfung verzichten (was sicher nicht im Sinne der Erfinder ist).

> 2) gibt es prinzipiell nur die Sorge, ob bestimmte Methoden verfügbar
>    sind, wenn sie aufgerufen werden. Selbst wenn man nur ganz einfache
>    (aber vollständige) Testsuites hat, fällt das auf. Zwar erst
>    zur Laufzeit, und nicht schon zur Compile-Zeit, aber immer noch
>    in der Testing-Phase, also lange bevor der Code auch nur irgendwie
>    ernsthaft gestartet wird. Und die Fehlersuche ist damit genauso
>    schnell, als würde es vom Compiler gefunden werden ... naja,
>    vielleicht ein paar Mikrosekunden später ...
>    Richtig tiefliegende Fehler findet man natürlich nicht, aber ich
>    wüsste andererseits auch kein Beispiel für so einen Fehler, der
>    nicht schon beim Programmieren ins Auge fallen würde.

Laut einer Erhebung von 1997 in den USA enthalten ausgelieferte 
Softwareprojekte durchschnittlich (!) 7 Fehler pro 100 Codezeilen...

> Ohne Testsuites ist Python aber ein ziemliches Wagnis, das stimmt. :-(
>
> > Wenn schon kein Compilierungs-Schritt da ist, sollte wenigstens eine
> > statische Analyse stattfinden, um den Programmierer zu unterstützen.
>
> Was bedeutet das? Kannst du das mal an einem Beispiel erläutern?

Hand aufs Herz: wie erzähl' ich's meinem Compiler? Ich versuche doch 
erstmal hinzuschreiben, was ich meine. Der Compiler sagt mir aber, dass 
er mich nicht versteht. Also sag' ich es ihm anders, und ich brauche 
einige Versuche, um ihn zufriedenzustellen. Dann guck' ich mir an, ob 
das, was ich jetzt gesagt habe, auch immer noch das ist, was ich meine. 
So entsteht ein Konsens zwischen mir und meinem Compiler, noch bevor 
einer von beiden auf die Idee kommt, irgendwas zu debuggen. Was würde 
ich einem Compiler/Interpreter erzählen, der jeden Unsinn akzeptieren 
würde?

Gruß,
			Axel

-- 
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **