Python Logik?

[Norbi]

Ich (Anfänger) bin momentan leicht verwirrt.

Code: Alles auswählen

D:\tmp>python
Python 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = range(3)
>>> a
[0, 1, 2]
>>> a[1:3] = [4,5,6]
>>> a
[0, 4, 5, 6]
>>> a[1:3]
[4, 5]
>>> a[3]
6
>>>

Kann mir bitte jemand die Logik erklären, die sich dahinter verbirgt?

Vielen Dank!

Gruß, Norbert

[BlackJack]

@Norbi: Was verwirrt Dich denn? Wo hättest Du etwas anderes erwartet und warum? Ich finde da nichts verwirrendes. Verhält sich so wie es in der Dokumentation steht.

[Norbi]

@Norbi: Was verwirrt Dich denn? Wo hättest Du etwas anderes erwartet und warum? Ich finde da nichts verwirrendes. Verhält sich so wie es in der Dokumentation steht.

Naja, mag sein, dass das so funktioniert wie es in der Doku steht aber wer hier als logisch denkender Mensch keine Kopfschmerzen bekommt, hat wirklich ein Wahrnehmungsproblem. Und als Programmierer sollte man eigentlich zur Kategorie der logisch denkenden Menschen gehören.

Sorry, dass ich das nun so hart formuliere aber man muss entweder schon ziemlich abgehärtet sein oder sich bis jetzt noch nicht mit einer anderen (vernünftigen?) Programmiersprache befasst haben, wenn einem sowas nicht sofort übel aufstößt.

Ich habe hier jedenfalls schon große Probleme mit der offensichtlich fehlenden Logik, die man eigentlich bei der Angabe von Feldindizes bzw. Bereichen derselben, erwarten würde. Sowas Kurioses kenne ich von keiner anderen Programmiersprache. Es gibt Indizes, die sind 0-basiert oder 1-basiert und bei einigen Sprachen kann man die Basis für Feldindizes wählen bzw. umschalten. Aber dass die Basis je nach Auswahl eines Index oder eines Indexbereichs eine andere ist, sowas Seltsames habe ich noch nie gesehen und ich habe mich schon mit so einigen Programmiersprachen befasst.

[Sirius3]

@Norbi: was Dich also wundert ist, dass bei einem Bereich der Endindex nicht mitgenommen wird. Das ist eine einfache Konvention und hat nichts mit seltsamer Logik zu tun, sondern nur Vorteile. Beispiel:
Du willst eine Liste am Element mit dem Wert 6 aufspalten:

Code: Alles auswählen

>>> a = [1,3,6,2,0]
>>> a.index(3)
1
>>> b = a.index(6)
>>> b
2
>>> a[:b]
[1, 3]
>>> a[b:]
[6, 2, 0]

Du willst ein Element an der Stelle 3 einfügen:

Code: Alles auswählen

>>> a[3:3]=[7]
>>> a
[1, 3, 6, 7, 2, 0]

Wie sollte das gehen, wenn 3:3 schon das dritte Element enthalten würde?

[Norbi]

Bleiben wir doch mal bei meinem Beispiel. Ich hätte z.B. bei Zeile 11 (logischerweise) erwartet, dass 3 Elemente des Feldes ausgegeben werden. Und zwar der Bereich mit den Feldindizes 1,2 und 3, also entweder [0, 4, 5] wenn die Basis des Feldindex 1 ist oder [4, 5, 6] wenn die Basis des Feldindex 0 ist. Das wäre sowohl von der Anzahl, als auch vom Inhalt eine logische Ausgabe. Und ich hätte in der Zeile 13 erwartet, dass hier die höchste Zahl der Ausgabe des Feldbereichs von der Zeile 11 (nämlich der Inhalt des Feldes mit dem Index 3) ausgegeben würde, was auch logischerweise zu erwarten gewesen wäre.

Das wären meine Erwartungen gewesen. Aber das, was ich hier sehe, ist nicht logisch und verwirrt mich.

[BlackJack]

@Norbi: Wer als logisch denkender Mensch dabei Kopfschmerzen bekommt hat einfach die Logik dahinter nicht verstanden.

Die Basis bei Bereichen ist keine andere, sondern das was die Zahlen bei Bereichen bedeuten ist etwas anderes. Bei einem Index ist das ein Element an der Stelle des Index, beginnend bei 0. Bei einem „slice” wählt man Punkte *zwischen* den Elementen aus, beginnend mit 0 was die Stelle vor dem ersten Element ist. Eine 1 ist die Stelle zwischen dem ersten und zweiten Element. Und so weiter. Es sind die Stellen durchnummeriert, an denen man einen Teilbereich ausschneidet. Bildlich:

Code: Alles auswählen

 0 1 2  <- Indexzugriff
+-+-+-+
|a|b|c| <- Elemente
+-+-+-+
0 1 2 3 <- „Slice”-Schnittpunkte

Ansonsten kann man sich auch mal durchlesen was Dijksra schon 1982 zu dem halboffenen Intervall zu sagen hatte, also wo der Wert am gegebenen Endindex nicht mehr im Ergebnis enthalten ist: https://www.cs.utexas.edu/users/EWD/tra ... WD831.html

[Norbi]

Ansonsten kann man sich auch mal durchlesen was Dijksra schon 1982 zu dem halboffenen Intervall zu sagen hatte, also wo der Wert am gegebenen Endindex nicht mehr im Ergebnis enthalten ist: https://www.cs.utexas.edu/users/EWD/tra ... WD831.html

Naja, das ist nun die alleinstehende Aussage eines einzelnen Informatikers, der früher mal an der Entwicklung der Programmiersprache Algol 60 beteiligt war (die sich nicht sonderlich lange gehalten hat) und dessen Aussagen (z.B. über die Verwendung von Goto usw.) später teilweise wieder revidiert wurden.

Als gutes Gegenbeispiel würde ich gerne die Programmiersprache Ada anführen.

http://en.wikibooks.org/wiki/Ada_Progra ... ypes/range

Hier heißt es ganz klar und unmissverständlich range First .. Last. Und diese Programmiersprache wurde u.a. auch speziell auf die syntaktische Sicherheit ihres Programmcodes entwickelt und dazu haben sich auch ein paar schlaue Köpfe ihre Gedanken gemacht. Steht wohl so ziemlich im Gegensatz zu den Ausführungen des Herrn Dijkstra.

Gut, ich möchte hier nun keinen Streit vom Zaun brechen. Das scheint bei Python wohl eine Definitionssache zu sein wobei man hier offensichtlich eine andere Ansicht darüber vertritt, was logisch schlüssig ist und womit ein Programmierer gedanklich die wenigsten Fehler macht.

[mcdwerner]

@Norbi: auf die Schnelle fallen mir Java und JavaScript ein, die ähnlich (=exklusive Endindex) "rechnen":

http://www.w3schools.com/jsref/jsref_substring.asp
http://docs.oracle.com/javase/7/docs/ap ... #substring(int, int)

So ganz ungewöhnlich ist der Ansatz also nicht...

edit: remove typo

[cofi]

Algol-Sprachen sind allerdings ziemlich verbreitet (C-Familie, Java, Python, Perl, ...) und siehe da sie halten sich alle an diese Konvention.
Das Problem ist schlichtweg: Es gibt nicht _den_ Common Sense, sondern er wurde durch Ausbildung und Umfeld gepraegt. Und da geht auch deine Argumentation fehl: Es gibt nicht den einen richtigen Weg. Pythons Sprachdesigner hatten eben die entsprechende Vorbildung, sodass eine solche Indizierung am meisten Sinn ergeben hat bzw am natuerlichsten war.

Der Punkt ist ganz einfach: Natuerlich ist das Definitionssache. Es wird eine kuenstliche Sprache mit ihren eigenen Axiomen und Praemissen geschaffen. Eine davon ist eben, dass ein halb-offenes Intervall bei einer 0-basierten Indizierung am hilfreichsten ist. Und gegen Axiome kann man nunmal nicht argumentieren.

Zu Ada und wie es tatsaechlich zu sichererem Code beitraegt gibt es dann auch noch ganz andere Meinungen ...

Dijkstras Argumentation gegen Goto hat sich uebrigens durch Strukturierte Programmierung (Schleifen-Konstrukte, Prozeduren, ...) ueberholt und die meisten blanken Gotos in C haette man nicht, gaebe es Syntaktische Unterstuetzung bei der Fehlerbehandlung.

[BlackJack]

@Norbi: Ich weiss nicht ob man Dijkstra einfach so als „alleinstehende Aussage eines einzelnen Informatikers” abtun kann. Zumal das bei einer sachlichen Begründung eigentlich auch egal sein sollte.

Bezüglich der Basis kannst Du Elementzugriff und „slices” als gleich ansehen. Wenn Du beides auf Elemente beziehst, dann ist die Basis offensichtlich 0, bei beiden. Wie Sirius3 schon sagte hängst Du die harten Worte offensichtlich daran auf, das der Endindex beim „slice” nicht im Ergebnis enthalten ist. Warum das so Sinn macht hat Sirius3 ja auch gezeigt. Und Dijkstra hat das auch ausgeführt.

[Hellstorm]

Ich finde hierbei immer den Vergleich mit der Entfernung gut.

Wenn mit dem Auto losfährt, ist der Start der Strecke ja auch bei Kilometer null. Und trotzdem ist es der erste Streckenabschnitt, obwohl man noch keinen einzigen Meter gefahren ist. Meinetwegen ist dann direkt am Start eine Sehenswürdigkeit, die ist dann ja an Position Null.

Zwischen dem ersten und dem dritten Kilometer hat man dann wieder drei Sehenswürdigkeiten:

Bei Kilometer 0 (Start): Sehenswürdigkeit A
Bei 1 km: Sehenswürdigkeit B
Bei 2 km: Sehenswürdigkeit C
Bei 3 km: Sehenswürdigkeit D
[A, B, C, D] (Ich verzichte hier mal auf die Anführungszeichen)

Und wenn man wissen will, welche Sehenswürdigkeiten zwischen Kilometer 1 und 3 sind, hat man eben Sehenswürdigkeit [B, C].

Wenn man aber genau wissen will, welche Sehenswürdigkeit bei Kilometer 3 ist, dann kriegt man D.


Naja, vielleicht etwas konstruiert und wahrscheinlich habe ich auch einen Denkfehler, aber ich mir hat das Beispiel immer mit den Indizes und der Länge von Listen geholfen.

[lackschuh]

Ich zitier mal von stackoverflow, was mir selbst die Erleuchtung brachte

Code: Alles auswählen

a[start:end] # items start through end-1
a[start:]    # items start through the rest of the array
a[:end]      # items from the beginning through end-1
a[:]         # a copy of the whole array

a[start:end:step] # start through not past end, by step

a[-1]    # last item in the array
a[-2:]   # last two items in the array
a[:-2]   # everything except the last two items

+---+---+---+---+---+
 | H | e | l | p | A |
 +---+---+---+---+---+
 0   1   2   3   4   5
-5  -4  -3  -2  -1

[Norbi]

Vielen Dank für die Erklärungen. Das macht die ganze Sache doch etwas verständlicher.

Gruß, Norbert