Allgemeine Frage zu Methoden und Funktionen

[Miranda]

Hallo ihr Lieben,

ich hab mal wieder eine mehr allgemeine Frage.

In Python ist ja alles ein Objekt, aber warum gibt es einerseits Funktionen und andererseits Methoden?

Beispiel: Eine Liste.

Code: Alles auswählen

ichListe = [ 1, 2, 3 ]
ichListe.append( 4 ) # Methode
ichListe.remove( 2 ) # Methode

Aber andererseits

Code: Alles auswählen

len( ichListe )

Warum gibt es hier nicht genauso und vor allem dann einheitlich eine Methode len in der Form:

Code: Alles auswählen

ichListe.len()

?

Weiß jemand warum das so uneinheitlich ist?

Liebe Grüße

[__deets__]

Das ist tatsaechlich nicht wirklich "schoen" zu begruenden. Sondern "einfach" eine Entscheidung aus der Vergangenheit. Oder Warze, je nach Perspektive Man kann sich da jetzt nachtraeglich Rechtfertigungen ausdenken, aber andere Sprachen wie Ruby machen das AFAIK anders. Den einzigen milden Nutzen den ich da sehen: wenn man sich zB C++ anschaut, dann gibt es da alle Moeglichen Varianten wie zB .count() oder .size() oder .num() oder oder oder. Durch das len-Protokoll (das ein Objekt die Methode __len__ ueberladen kann) hat man so zumindest leicht eine Schubs in Richtung von "macht das alle gleich" gemacht. Aber wie gesagt, das ist am Ende auch nicht zwingend und eine Geschmackssache.

[Miranda]

Ah, danke.
Das mit den unschönen "Warzen" kenne ich von Java und PHP. Von daher ist Python da ja in ganz guter Gesellschaft

Es hätte ja ansonsten sein können, dass es wirklich einen guten (?) Grund dafür gäbe - aber dann sind das wohl ganz normale "Warzen" in Python.

Vielen Lieben Dank!!

[__blackjack__]

Es gab mal einen wirklich guten (?) Grund dafür: Bis (einschliesslich) CPython 2.1 gab es einen Unterschied zwischen Typen (die man nur in C implementieren konnte) und Klassen, und die Grunddatentypen mit einer Länge wie `str`, `list`, … sind in C implementiert und hatten damals keine `__len__()`-Methode. Ohne die `len()`-Funktion die ebenfalls in C implementiert ist und die Datenstruktur von in C geschriebenen Typen kannte, konnte man die Länge von diesen Objekten nicht von Python-Code aus abfragen.

Natürlich kann man die Unterscheidung zwischen Typen und Klassen in Frage stellen, aber ich denke mal als Python gestartet ist, machte es noch Sinn das man Typen hatte die in C geschrieben sein mussten und nicht so flexibel waren, dafür dann aber schneller und kompakter.

Edit: Die Entscheidung hätte man zum Umstieg auf Python 3 übrigens überdenken können, was nicht gemacht wurde. Im Gegenteil wurde beispielsweise aus der `next()`-Methode von Iteratoren eine `__next__()`-Methode + ”neuer” `next()`-Funktion. Die Python-Entwickler scheinen so etwas also ganz und gar nicht als Warze zu sehen.

[nezzcarth]

Hier Mal eine Auskunft von Guido Van Rossum dazu: http://effbot.org/pyfaq/why-does-python ... n-list.htm

Und wen man Methoden mag, wäre vielleicht wirklich Ruby einen Blick wert. Da kann man dann sogar sowas schreiben: '5.times { … }'.

[snafu]

Ich denke, es gibt schlimmeres. Python hat nicht den Anspruch, gänzlich objektorientiert zu sein. Wozu also der Aufwand? Zudem wäre es eine weitere Inkompatibilität zu altem Code. Sind ja eh schon reichlich Änderungen gemacht worden beim Sprung auf Python 3. Man müsste dann konsequenterweise das gesamte Dunder-Konzept über Board schmeißen, da das alles ja auch mit "normalen" Methodennamen möglich ist. Will man das wirklich?

[__blackjack__]

@snafu: Nein, natürlich nicht. Einen wirklich guten Grund (diesmal ohne Fragezeichen) hat Guido ja in dem von nezzcarth verlinkten Artikel genannt: Die Gefahr das man aus versehen besondere Methoden implementiert wenn die keine besonderen Namen haben. Darum ja auch von `next()` nach → `__next__()` von Python 2 nach 3. `next` ist beispielseweise üblicher Attributname bei der Implementierung von verketteten Listen. `add()` ist auch so ein Name den man gerne auch mal hätte ohne das der gleichzeitig den ``+``-Operator überschreibt. Und mit den speziellen Namen kann man auch in Zukunft welche einführen ohne sich Sorgen machen zu müssen vorhandenen Code damit kaputt zu machen.

Wobei Funktionen in Python ja auch Objekte sind, man könnte also auch argumentieren das `len` ein Objekt ist dem man andere Objekte als Nachricht schicken kann, und dass dann mit deren Länge antwortet. Total objektorientiert.