Methoden <-> Klassen !?

Christian Tismer tismer at appliedbiometrics.com
Sat May 9 23:33:12 EDT 1998


Status: RO

Hi Alle, Thomas, Schorsch,

meine 0.02 Ecu noch dazu...

> Der Datentyp "string" ist in Python (aehnlich wie ein Modul) zwar
> ein "first class object", aber nicht im ganz engen Sinne eine "Instanz der
> Klasse String". Wenn Du den String nicht in eine selbstgebackene Klasse
> einbettest, dann kannst Du ihn nur mit externen Funktionen manipulieren.
> Im Python-Jargon ist ein String ein "attribute-less object". Am deutlichsten
> wird das durch  folgenden Test:
> 
> >>> "abc".__methods__
> Traceback (innermost last):
>     File "<stdin>", line 1, in ?
> AttributeError: attribute-less object

Das ist übrigens wahr, aber dir("abc") liefert in Py1.5 immerhin brav 
eine leere Liste ab.

Zu dem generellen Gemisch ein paar Worte:
Ich glaube nicht, daß Guido es so wollte, aber im Laufe der Zeit hat
sich ein etwas heterogenes Bild ergeben.

Euer Beispiel "string" ist von der Sorte: Strings können nur weniges
in "Objekt-manier", aber "a"+"b" läuft durchaus auf das Äquivalent
eines Methodenaufrufs hinaus. Das hat nun mit dem Modul "string"
überhaupt nichts zu tun, das ist (ursprünglich) ein reines Python-
-Modul. Später sind dann pö a pö Funktionen in das builtin-module
strop gewandert. Aber ist einfach eine Funktionensammlung.

Jetzt zu den Methoden von Built-ins:
Das "a"+"b" war bereits ein aufruf von in der Tat vorhandenen
Methoden des Typ's "string" (ich sage absichtlich Typ, siehe
weiter unten).
Ein weiteres Beispiel sind etwa die Listen, sie haben schon allerhand
an eingebauten echten Methoden zu bieten:

>>> dir([])
['append', 'count', 'index', 'insert', 'remove', 'reverse', 'sort']
>>> 

Und daß das richtige Methoden sind, sieht man leicht daran, indem
man das Python-Konzept der gebundenen Methoden benutzt:

>>> lis=[]
>>> lisadd=lis.append  # daaa isses
>>> lisadd(3)
>>> lis
[3]
>>> 

Also hier haben wir's mit richtigen Methoden zu tun.

Jetzt die Hammerfrage, die mich 'ne Menge Zeit gekostet hat zu
kapieren:
Was ist diese Liste denn nun, Klasseninstanz oder Typinstanz?
Eindeutig eine Typinstanz, denn type(lis) liefert <type 'list'>
zurück.
Als ich das erste mal anfing, meine eigenen Klassen zusammenzu-
-pfriemeln, fand ich das sehr merkwürdig. Die Dinger haben Methoden,
aber lis.__class__ gibt AttributeError: __class__
Und meine eigenen Typen (also Klassen oder was? dachte ich), haben
komischerweise alle einen gemeinsamen Typ:

>>> class myclass :
... 	pass
... 	
>>> myinst = myclass()
>>> type(myclass)
<type 'class'>
>>> type(myinst)
<type 'instance'>
>>> 

Das heißt, für unsere selbstgebauten "Typen" gibt's nur zwei
"richtige" Typen, class und instance.

An dieser Stelle hat sich Python intern ein wenig gespalten.
Während es ganz normal und relativ einfach ist, neue Typen
mit Methoden als C-Module zu implementieren, ist Guido
für die in Python selbst implementierten Objekte einen ganz
anderen Weg gegangen, auch der Einfachheit halber. Es wäre
zwar schön (und vermutlich wird's auch mal so), wenn beide
Konzepte vereinheitlicht würden, aber im Moment geht's einfach
nicht.

Zusammenfassend: Eingebaute Typen habe Methoden, wie 
selbstdefinierte Klassen sie haben. Aber Deine Klassen können
keinen neuen Typ bekommen, das Typ-Konzept ist hier zu Ende.

Wenn ich es richtig sehe, wird der Zug in Zukunft eher in Richtung
Python-Klassen weiterfahren. Die neuen Funktionen issubclass
und isinstance sind absichtlich so gebaut worden, daß sie auch
mit "Typen" richtig umgehen:

Neben dem eigentlichen Sinn der Funktion:

>>> isinstance(myinst, myclass)
1
>>> 

klappt nämlich auch

>>> isinstance("abc", type(""))
1
>>> 

das heißt, hier wird bereits so getan, als sei "alles in Ordnung"
d.h. das Typ/Klassenkonzept wäre aus einem Guß.

Wer hier halbwegs zukunftsstabil programmieren will, sollte, wenn
er Typen benutzt, an Klassen denken, und wenn möglich nicht auf
Typen zurückgreifen, sondern mit isinstance die Zugehörigkeit
abfragen.

> Hoffe etwas zur Verwirrung beigetragen zu haben ;)

ick ooch - pirx

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.skyport.net
10553 Berlin                 :     PGP key -> http://pgpkeys.mit.edu
     we're tired of banana software - shipped green, ripens at home




More information about the Python-de mailing list