Das deutsche Python-Forum

Mir kam gerade die Frage, was denn wohl ein string ist?

Ein tuple, dessen Element(e) auf diverse strings (???) verweist. Also etwas in der Art

Ein String ist kein Tupel, s. auch in der Doku. http://docs.python.org/reference/datamo ... -hierarchy und dort unter `Immutable sequences`.

Soweit ich das lese, sind sowohl tuple wie auch string eine Sequenz. Wobei ein string eben schon mit einem oder mehreren Zeichen gefüllt ist und natürlich andere bzw. weitere Methoden besitzt.

Ich möchte mich aber jetzt gar nicht so sehr auf 'tuple' oder 'nicht tuple' versteifen. Mit geht es darum, ob Python 'intern' einen wirklichen Unterschied zwischen einem 'tuple' und einem 'string' macht.

Dann solltest du wohl in den Code schauen.

Wie kommst du denn auf den Gedanken, dass es ein Tuple sein sollte? Weil beide unveraenderlich sind?!

Code: stringobject.c, tupleobject.c
Aber letztendlich sind es doch alle "PyObject"s.

cofi hat geschrieben:Wie kommst du denn auf den Gedanken, dass es ein Tuple sein sollte?

Ganz so abwegig ist der Gedanke nicht, ähnlich wird mit "Strings" und Listen ind Haskell verfahren. Aber ich empfehle auch einen Blick in den Code. Der ist nicht besonders lang und dort steht es ganz genau.

In Haskell ist String nur ein alias für [Char], Python hat mit unicode einen eigenen Typen der sich nicht irgendwie aus anderen Typen zusammensetzt.

Ich kann mich auch irren, aber der Code(python 2.7) sieht für mich schon sehr eigenständig aus.

EyDu hat geschrieben:Ganz so abwegig ist der Gedanke nicht, ähnlich wird mit "Strings" und Listen ind Haskell verfahren.

Andererseits ist es auch nicht so abwegig das Strings eigenständig sind, denn in C gab es diese ja schon als char*. Tuples sind da doch schon schwerer umzusetzen.

mutetella hat geschrieben: Ich möchte mich aber jetzt gar nicht so sehr auf 'tuple' oder 'nicht tuple' versteifen. Mit geht es darum, ob Python 'intern' einen wirklichen Unterschied zwischen einem 'tuple' und einem 'string' macht.

Nuja, ich würde es mal so sagen: Es existieren nun einmal die Namen "Tupel" und "String". Wozu sollte man das unterscheiden, wenn es keinen semantischen Unterschied gibt? :K Mir fielen da nur Kompatibilitätsgründe ein, die dann aber dokumentiert wären. Das alleine suggeriert zumindest schon mal die Unterschiedlichkeit.

Ein zusätzlicher Blick in den Code schadet natürlich nicht

Xynon1 hat geschrieben:Ich kann mich auch irren, aber der Code(python 2.7) sieht für mich schon sehr eigenständig aus.

EyDu hat geschrieben:Ganz so abwegig ist der Gedanke nicht, ähnlich wird mit "Strings" und Listen ind Haskell verfahren.

Andererseits ist es auch nicht so abwegig das Strings eigenständig sind, denn in C gab es diese ja schon als char*. Tuples sind da doch schon schwerer umzusetzen.

Ich wollte mit meinem Hinweis nicht über die interne Struktur spekulieren, sonder andeuten, dass es auch andere Wege als den "Standardweg", welcher bei Python ganz offensichtlich eingeschlagen wurde, gibt. Als Gründe für eine Unterscheidung sehe ich vorallem Operationen, welche nicht auf beiden Strukturen Sinn ergeben und Performancegewinne. Von der Umsetzung sind Tupel genau so einfach wie Strings.

@EyDu
Das streite ich auch gar nicht ab, nur das Tuples in einer statisch typisierten Sprache genauso "einfach" wie Strings umzusetzen sind, kann ich irgendwie nicht glauben. Ich möchte nicht behaupten das es schwer ist, aber ist es nicht etwas komplexer eine Sequenz mit unterschiedlichen Datentypen umzusetzen, als eine mit gleichen?

@Xynon1: Wenn es einen "Obertyp" gibt, sehe ich da keine Probleme. Also zum Beispiel so etwas wie `object` wovon alles andere Untertypen sind. Andere Sprachen, ohne so eine feste Typhierarchie, haben dann zum Beispiel einen speziellen Platzhaltertypen der `Any` oder `Variant` oder so heisst. Gibt es zum Beispiel in einigen BASIC-Dialekten. Oder auch »Pointer auf "irgendein Ding"«, also so etwas wie ``void *`` in C.

cofi hat geschrieben:Wie kommst du denn auf den Gedanken, ...

Nun ja, weil sich ein string ähnlich wie ein tuple verhält und letztlich doch nur über mehr Methoden verfügt.
Und würde es in Python nur Zeichen, aber keine strings geben, würde eine Klasse 'String()', die man sich dann zwangsläufig basteln müsste, ihre items intern auch ähnlich einem 'tuple' oder einer 'list' verwalten.

cofi hat geschrieben:Dann solltest du wohl in den Code schauen.

Spätestens hier muss ich aussteigen und verweile in ehrfürchtigem Staunen...

Hat man mir damals nicht gerade deshalb auch Python empfohlen, weil ich mir dann über solche Dinge keinen Kopf machen muss...?

mutetella

Ja, dass das mit Objekten oder auch mit »Pointer auf "irgendein Ding"« funktioniert ist mir auch klar. Dennoch ist es doch so, das eine Zeichenkette nunmal schneller angelegt ist.
Ich wollte das eigentlich nur sagen das man nicht erst das Tuple in C erfinden musste, um ein PyStringObject zubauen. Die Ähnlichkeit wie beide Strukturen in Python genutzt werden ist ja nun nicht zu übersehen, die Frage von mutetella war schon berechtigt.

mutetella hat geschrieben:...und verweile in ehrfürchtigem Staunen...

So schön sieht der C-Code nun auch wieder nicht aus

BlackJack hat geschrieben:@Xynon1: Wenn es einen "Obertyp" gibt, sehe ich da keine Probleme. Also zum Beispiel so etwas wie `object` wovon alles andere Untertypen sind. Andere Sprachen, ohne so eine feste Typhierarchie, haben dann zum Beispiel einen speziellen Platzhaltertypen der `Any` oder `Variant` oder so heisst. Gibt es zum Beispiel in einigen BASIC-Dialekten. Oder auch »Pointer auf "irgendein Ding"«, also so etwas wie ``void *`` in C.

Das gilt aber ueblicherweise nicht fuer die hier genannten funktionalen Sprachen (Erlang koennte da ne Ausnahme sein, es vereint ja die Nachteile interpretierter & funktionaler Programmierung unnachahmlich... ). Da musst du schon explizite Summentypen definieren, einen impliziten "von allen" gibt's nicht. Tupel sind dann auch eher nicht, sondern listen - also cons-zellen mit Zeiger auf Kopf + Rest. Aber weil halt funktional, dann doch immutable, wie Python's Tupel...

Ich bezweifele aber, dass es eine sinnvoll genutzte Sprache gibt, die nicht einen string-datentypen zwar algebraisch als spezialisierten Typen einer generischen Liste mit Typ = char definiert, aber dann doch "under the hood" durch eine effiziente byte-array-basierte Implementation autauscht. Was ja gerade das schoene so einer Definition ist

mutetella hat geschrieben:Hat man mir damals nicht gerade deshalb auch Python empfohlen, weil ich mir dann über solche Dinge keinen Kopf machen muss...?

Und warum tust du es dann immer?

Die Frage ist immer, ob man sich mit den Implementierungsdetails auseinandersetzen will oder ob man lieber gegen eine definierte Semantik programmiert.
Ich bevorzuge letzteres, du scheinst da wohl mehr auf ersteres zu stehen

Die Antwort auf deine urspruengliche Frage ist - wenn man nicht in die Implementierungsdetails gehen will: Ein Python-Primitivum. Fertig.

@EyDu:
Da waer ich jetzt vorsichtig, wie DasIch schon geschrieben hat, sind das da keine Tupel, sondern Listen. Und die vorrangige Eigenschaft der Haskell-Tupel ist, dass man da verschiedene Datentypen mischen kann.

Xynon1 hat geschrieben:Das streite ich auch gar nicht ab, nur das Tuples in einer statisch typisierten Sprache genauso "einfach" wie Strings umzusetzen sind, kann ich irgendwie nicht glauben. Ich möchte nicht behaupten das es schwer ist, aber ist es nicht etwas komplexer eine Sequenz mit unterschiedlichen Datentypen umzusetzen, als eine mit gleichen?

Gut, ein Beispiel in wenigen Minuten zusammengeschrieben. Die untere Hälfte besteht nur aus Beispiel und syntaktischem Zucker, lediglich die Klasse ist wirklich interessant.

cofi hat geschrieben:@EyDu:
Da waer ich jetzt vorsichtig, wie DasIch schon geschrieben hat, sind das da keine Tupel, sondern Listen. Und die vorrangige Eigenschaft der Haskell-Tupel ist, dass man da verschiedene Datentypen mischen kann.

Wenn man möchte, kann man sich natürlich in unwichtigen Beispielen verfangen und dieses vollkommen überziehen Es ging um die prinzipielle Machbarkeit.

Der Verweis aus Haskell ist nur bedingt sinnvoll, zu unterschiedlich sind Typsystem und Semantik von Haskell und Python.

Haskells Definition einer Zeichenkette als eine Liste von Zeichen ist wohl auch auch weniger Resultat gründlichen Entwurfs, sondern eine aus der Not geborene Entscheidung. Generische Funktionen wie "map" sind in Haskell für Listen definiert, nicht aber für allgemeine iterierbare Objekte, da Haskell für letzteres keine Typklasse bietet. Aus praktischen Erwägungen ist es also sinnvoll, Zeichenketten als [Char] zu definieren, da man ansonsten all diese generischen Funktionen für Zeichenketten nochmals implementieren müsste.

@deets: Der GHC, die verbreiteste Haskell-Implementierung, kompiliert Zeichenketten in eine verkettete Liste von Zeichen, und nicht in ein Feld. Es findet keine spezielle Optimierung statt, insbesondere keine besondere Implementierung. Listen verschiedener Typen sind zwar algebraisch verschieden, müssen aber zur Implementierung polymorpher Listenfunktionen letztlich eine gemeinsame Binärschnittstelle besitzt. Eine spezielle Implementierung für einen bestimmten Listentypen erzeugt allerdings auch eine spezielle Binärschnittstelle.

Folglich muss die Optimierung entweder unter Verzicht auf eine stabile Binärschnittstelle über den gesamten Programm inklusive aller verwendeten Module durchgeführt werden, oder jedwede polymorphische Funktion für jede spezielle Implementierung eines Listentyps sowie für generische Listen kompilieren. Beides ist nicht praktikabel und mithin im GHC nicht implementiert. "String" ist in Haskell daher chronisch ineffizient, so dass man oft Data.Bytestring für I/O verwendet und nur bei Bedarf umwandelt.

Die Sprachen der ML-Familie, zur der wohl alle anderen, praktisch genutzte Sprachen mit deselben Typsystem wie Haskell gehören, definieren Zeichenketten daher nicht als Liste von Zeichen, sondern einen eigenen Typen für Zeichenketten. Dann wird semantisch klar getrennt zwischen diesen Typen, so dass man sie auch unterschiedlich implementieren kann. Der Nachteil ist natürlich, dass man generische Listenfunktionen dann nicht auf Zeichenketten anwenden kann.

@EyDu
Jupp, schönes Snippet. char* ist trotzdem schneller geschrieben und wie bekomme ich da jetzt mehrere Datentypen rein?

Bitte mach dir jetzt keine Mühe das auch noch einzubauen, ich weiß das geht. Mein Standpunkt war nur das es nicht so "einfach" ist.

cofi hat geschrieben:Und warum tust du es dann immer?

Weil ich glaube, dass gerade beim Programmieren ein theoretisches Verständnis dessen, was Du ein Primitivum nennst sich letztlich in 'besserem' Code niederschlägt.
Und wenn ich mehr über die Hintergründe, die ja spätestens bei ihrer Anwendung im Vordergrund stehen, erfahre, umso mehr Spaß macht das alles letztlich...

cofi hat geschrieben:... oder ob man lieber gegen eine definierte Semantik programmiert.

Was meinst Du damit: gegen eine definierte Semantik?

mutetella