Hallo, ich schreibe zur Zeit einen Artikel über Python, und dabei gerade etwas über Slicing in Sequenzen. Dabei ist mir aufgefallen, dass es nicht unmittelbar einleuchtend ist, warum man mit
L = [19, 37, 8, 9] L[1:3] [37, 8]
bekommt und nicht etwa [37, 8, 9], die Werte für die in der Slice-Syntax angegebenen Indices 1 bis 3. Gibt es eine für Python-Einsteiger nachvollziehbare Erklärung, warum sich Slicing (und die range-Anweisung) so verhalten, wie sie es tun? Bei http://www.jandecaluwe.com/Tools/MyHDL/manual/intro-slicing.html habe ich gerade folgendes dazu gefunden: """ The half-openness of a slice may seem awkward at first, but it helps to avoid one-off count issues in practice. For example, the slice hex[8:] has exactly 8 bits. Likewise, the slice hex[7:2] has 7-2=5 bits. """ Ich weiß nicht, ob mich diese Erklärung überzeugt. :-) Mich hat die Python-Konvention irritiert, als ich zum ersten Mal gemerkt habe, dass man eine "lückenlose" Folge bekommt, wenn man L[:5] + L[5:] schreibt, und nicht etwa L[:5] + L[6:] wie ich es zuerst geschrieben hatte. (Der Code lautete natürlich nicht so, aber er war vom Sinn her ähnlich.) Sonst hatte ich allerdings nie Probleme mit Pythons Slicing-Konvention. Kennt jemand von euch noch andere Erklärungen oder Hintergründe zu diesem Thema? Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
[Sorry, Stefan, für die Email. Also das Ganze nochmal an die Liste] Hallo! On 14 Aug 2004 at 20:54, Stefan Schwarzer wrote:
bekommt und nicht etwa [37, 8, 9], die Werte für die in der Slice-Syntax angegebenen Indices 1 bis 3. Gibt es eine für Python-Einsteiger nachvollziehbare Erklärung, warum sich Slicing (und die range-Anweisung) so verhalten, wie sie es tun?
>>>> The best way to remember how slices work is to think of the indices as
Die 1 und 3 stehen ja eher für die Zwischenräume, an denen die Sequenz aufgetrennt wird. Siehe auch "3.1.2 Strings" im Tutorial: pointing between characters, with the left edge of the first character numbered 0. Then the right edge of the last character of a string of n characters has index n, for example: +---+---+---+---+---+ | H | e | l | p | A | +---+---+---+---+---+ 0 1 2 3 4 5 -5 -4 -3 -2 -1 <<<<<<<<<< Anfänglich leuchtete mir nicht ein, warum das letzte Element mit bla[-1] angesprochen wird und nicht mit bla[-0] (mal vom Problem abgesehen, 0 und -0 voneinander unterscheiden zu können). bla[-1] muss man eben auch lesen als das Element hinterm vorletzten Zwischenraum. Jan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 14 Aug 2004 at 22:51, Jan Voges wrote:
als das Element hinterm vorletzten Zwischenraum.
'letzten' natürlich. Jan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Jan, danke für die Antwort. :-) On Sat, 2004-08-14 22:51:43 +0200, Jan Voges wrote: Content-Description: Mail message body
[Sorry, Stefan, für die Email. Also das Ganze nochmal an die Liste]
kein Problem.
On 14 Aug 2004 at 20:54, Stefan Schwarzer wrote:
bekommt und nicht etwa [37, 8, 9], die Werte für die in der Slice-Syntax angegebenen Indices 1 bis 3. Gibt es eine für Python-Einsteiger nachvollziehbare Erklärung, warum sich Slicing (und die range-Anweisung) so verhalten, wie sie es tun?
Die 1 und 3 stehen ja eher für die Zwischenräume, an denen die Sequenz aufgetrennt wird.
>>>>> The best way to remember how slices work is to think of the indices as
Siehe auch "3.1.2 Strings" im Tutorial: pointing between characters, with the left edge of the first character numbered 0. Then the right edge of the last character of a string of n characters has index n, for example:
+---+---+---+---+---+ | H | e | l | p | A | +---+---+---+---+---+ 0 1 2 3 4 5 -5 -4 -3 -2 -1 <<<<<<<<<<
Anfänglich leuchtete mir nicht ein, warum das letzte Element mit bla[-1] angesprochen wird und nicht mit bla[-0] (mal vom Problem abgesehen, 0 und -0 voneinander unterscheiden zu können). bla[-1] muss man eben auch lesen als das Element hinterm vorletzten Zwischenraum.
Das erklärt ja durchaus, wie man sich das tatsächlich in Python verwendete Slicing erklären kann. Worauf ich aber eher abzielte bzw. abzielen wollte: _Warum_ wurde die Konvention so gewählt? (Und nicht: Wie kann man die Konvention _im nachhinein_ erklären?) Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Schwarzer wrote: | Das erklärt ja durchaus, wie man sich das tatsächlich in Python | verwendete Slicing erklären kann. Worauf ich aber eher abzielte bzw. | abzielen wollte: _Warum_ wurde die Konvention so gewählt? (Und nicht: | Wie kann man die Konvention _im nachhinein_ erklären?) Weil die Null in der religionslosen Computerwelt als Zahl akzeptiert ist, und somit unser Zahlensystem bei 0 anfängt, und nicht bei 1. Gruß ~ Daniel - -- Once the philosopher stone has fallen from the tree, ~ nonsense appeared to fix the courious fear. .. . .. ... . . .. . ... . .. . ... . . . pgp key @ http://files.poelzi.org/pgp.txt ED80 E53D 5269 4BB1 1E73 3A53 CBF9 A421 0A7B 003D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFBIAMOy/mkIQp7AD0RAqg8AJ0WE1dIzqH6dv/28B7MaiP3TYb1NwCdF8uF djZi/ZBzQ1779d93SxGPPtc= =3761 -----END PGP SIGNATURE----- _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
* daniel.poelzleithner [2004-08-16 02:42]:
Stefan Schwarzer wrote:
| Das erklärt ja durchaus, wie man sich das tatsächlich in Python | verwendete Slicing erklären kann. Worauf ich aber eher abzielte bzw. | abzielen wollte: _Warum_ wurde die Konvention so gewählt? (Und nicht: | Wie kann man die Konvention _im nachhinein_ erklären?)
Weil die Null in der religionslosen Computerwelt als Zahl akzeptiert ist, und somit unser Zahlensystem bei 0 anfängt, und nicht bei 1.
Es gibt nicht "die Konvention", sondern es gibt durchaus auch "Computerwelten", in denen die Indices mit 1 beginnen, z.B. in Fortran. Mit allerlei Konsequenzen für die Zusammenarbeit von Fortran- und C-Code. Ein Vorteil von 0...n-1 ist schlicht und ergreifend, dass es die Berechnung der Speicheradresse eines Array-Elementes erleichtert, da im Speicher der Versatz des ersten Elementes zum Beginn eines Arrays nämlich null ist. Joachim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo, inzwischen hat der Thread größere Ausmaße angenommen, als es (selbst mir) vielleicht wert ist. :-) Ich hatte gehofft, dass es eine einfache Antwort gibt, die mir bloß nicht eingefallen ist. Danke an alle, die geantwortet haben. Ich will aber noch anmerken, was ich meinte (und vielleicht hat dann doch noch jemand eine gute Antwort :) ) ... On Mon, 2004-08-16 02:42:55 +0200, daniel.poelzleithner wrote:
| Das erklärt ja durchaus, wie man sich das tatsächlich in Python | verwendete Slicing erklären kann. Worauf ich aber eher abzielte bzw. | abzielen wollte: _Warum_ wurde die Konvention so gewählt? (Und nicht: | Wie kann man die Konvention _im nachhinein_ erklären?)
Weil die Null in der religionslosen Computerwelt als Zahl akzeptiert ist, und somit unser Zahlensystem bei 0 anfängt, und nicht bei 1.
Ich wollte gar nicht darauf hinaus, dass das erste (bzw. nullte? ;-) ) Element einer Liste mit Null indiziert wird. Was ich meinte, ist: Warum bekommt der zweite Index eines Slice nicht den Index des betreffenden Elements aus der Liste, sondern muss um eins größer gewählt werden? Naheliegender(?) wäre doch: L = [34, 7, 19, 23] L[1] == 7 # stimmt in Python L[3] == 23 # stimmt in Python L[1:3] = [7, 19, 23] # stimmt _nicht_ in Python; L[1:3] ergibt [7, 19] ^ ^ L[1] L[3] Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Was ich meinte, ist: Warum bekommt der zweite Index eines Slice nicht den Index des betreffenden Elements aus der Liste, sondern muss um eins größer gewählt werden?
Naheliegender(?) wäre doch:
L = [34, 7, 19, 23] L[1] == 7 # stimmt in Python L[3] == 23 # stimmt in Python L[1:3] = [7, 19, 23] # stimmt _nicht_ in Python; L[1:3] ergibt [7, 19] ^ ^ L[1] L[3]
das ist nicht naheliegender, sondern nur die Vorstellung die du im Kopf hast, weil du's evtl. so gewohnt bist. Die Frage läßt sich erstmal reduzieren auf: Ist es ein geschlossenes oder halboffenes Intervall. Bei Python hat man sich für halboffen entschieden. Richtig und falsch in dem Sinne gibt's da nicht, aber ich schätze der Grund ist Code, der besser lesbar ist - wofür Python ja bekannt ist. In C++ zeigen Iterator aus der STL am Schluß auch hinter das letzte Element. Damit lassen sich viele Algorithmen besser schreiben. X = L[0:len(L)] # würdest du hier gerne len(L)-1 schreiben? X = L[0:2] + L[2:len(L)] # finde ich sauber als [0:2]+[3:len(L)] Kann natürlich sein, daß ich C++ 'geschädigt' bin, was ich aber nicht schlecht finde! ;-) Gruß, Achim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
sich viele Algorithmen besser schreiben.
X = L[0:len(L)] # würdest du hier gerne len(L)-1 schreiben?
X = L[0:2] + L[2:len(L)] # finde ich sauber als [0:2]+[3:len(L)]
das müsste heissen "finde ich sauberer als [0:2] + [3:len(L)+1]", was noch unlesbarer ist. insbesondere lässt sich beim python-slicing die anzahl der elemente leichter berechnen... gruss, uwe _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Am Montag, 16. August 2004 10:25 schrieb Stefan Schwarzer:
[...]
Was ich meinte, ist: Warum bekommt der zweite Index eines Slice nicht den Index des betreffenden Elements aus der Liste, sondern muss um eins größer gewählt werden?
Naheliegender(?) wäre doch:
L = [34, 7, 19, 23] L[1] == 7 # stimmt in Python L[3] == 23 # stimmt in Python L[1:3] = [7, 19, 23] # stimmt _nicht_ in Python; L[1:3] ergibt [7, 19] ^ ^ L[1] L[3] [...]
Ein Grund könnte sein, daß sich mit der in Python gewählten Konvention Slices der Länge Null ziemlich natürlich darstellen lassen (und die können als Abbruchkriterium für Iterationen sehr nützlich sein). Insgesamt erscheint IMHO das Berechnen von Eigenschaften von Slices mit der gewählten Konvention ziemlich natürlich. Z.B. gilt für die Länge eines Slice (für positive Indizes und a <= b): len(l[a:b]) = b - a. Grüße, Christian _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Christian Mönch <christian.moench@web.de> schrieb:
Am Montag, 16. August 2004 10:25 schrieb Stefan Schwarzer:
[...]
Was ich meinte, ist: Warum bekommt der zweite Index eines Slice nicht den Index des betreffenden Elements aus der Liste, sondern muss um eins größer gewählt werden?
Naheliegender(?) wäre doch:
L = [34, 7, 19, 23] L[1] == 7 # stimmt in Python L[3] == 23 # stimmt in Python L[1:3] = [7, 19, 23] # stimmt _nicht_ in Python; L[1:3] ergibt [7, 19] ^ ^ L[1] L[3] [...]
Ein Grund könnte sein, daß sich mit der in Python gewählten Konvention Slices der Länge Null ziemlich natürlich darstellen lassen (und die können als Abbruchkriterium für Iterationen sehr nützlich sein).
Die sind auch sonst nützlich:
l = range (5) l [2:2] = range (42, 44) l [0, 1, 42, 43, 2, 3, 4]
Sagt-einer-der-Datenstrukturen-immer-1-basiert-definierte, -- Christian Tanzer http://www.c-tanzer.at/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Am Montag, 16. August 2004 10:25 schrieb Stefan Schwarzer:
[...]
Was ich meinte, ist: Warum bekommt der zweite Index eines Slice nicht den Index des betreffenden Elements aus der Liste, sondern muss um eins größer gewählt werden?
Naheliegender(?) wäre doch:
L = [34, 7, 19, 23] L[1] == 7 # stimmt in Python L[3] == 23 # stimmt in Python L[1:3] = [7, 19, 23] # stimmt _nicht_ in Python; L[1:3] ergibt [7, 19] ^ ^ L[1] L[3] [...]
Ein Grund könnte sein, daß sich mit der in Python gewählten Konvention Slices der Länge Null ziemlich natürlich darstellen lassen (und die können als Abbruchkriterium für Iterationen sehr nützlich sein). Insgesamt erscheint IMHO das Berechnen von Eigenschaften von Slices mit der gewählten Konvention ziemlich natürlich. Z.B. gilt für die Länge eines Slice (für positive Indizes und a <= b): len(l[a:b]) = b - a. Grüße, Christian _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (9)
-
Achim Domma (Procoders) -
Christian Mönch -
Christian Mönch -
daniel.poelzleithner -
Jan Voges -
Joachim Saul -
Stefan Schwarzer -
tanzer＠swing.co.at -
Uwe Schmitt