Listenelemente mit 'Trennzeichen' trennen...

[mutetella]

Hallo,

der Threadtitel ist nicht ganz korrekt, ich kann das aber gerade nicht besser ausdrücken, sorry...

Gibt es für folgendes Beispiel eine bessere Lösung oder gar eine bestehende Standardfunktion, die ich wieder einmal nicht finden kann?

Code: Alles auswählen

current = ['a', 'b', 'c']
filler = '.'
new = []
for element in current:
    new.extend([element, filler])

new
['a', '.', 'b', '.', 'c', '.']

Danke!

mutetella

[Hyperion]

Guck mal hier

Übertragen auf Dein Problem:

Code: Alles auswählen

In [84]: list(chain.from_iterable(izip(current, repeat("."))))
Out[84]: ['a', '.', 'b', '.', 'c', '.']

[mutetella]

Jepp... vielen Dank!

Nach 'Inverses itertools.tee(), quasi izip() ohne Tupel' hatte ich noch nicht gesucht...

Wobei, wenn das einzufügende Element immer dasselbe ist, finde ich meine Lösung irgendwie schöner...

Oder spricht etwas dagegen, auf das ich nicht geachtet hab'?

mutetella

[Hyperion]

Wobei, wenn das einzufügende Element immer dasselbe ist, finde ich meine Lösung irgendwie schöner...

Oder spricht etwas dagegen, auf das ich nicht geachtet hab'?

Ist wohl Geschmackssache - ich finde meine schöner

Prinzipiell nehmen die sich nicht viel. Du erzeugst halt noch eine neue Liste [element, filler] im new.extend()-Aufruf. Daher wird Deine Variante wohl etwas mehr kosten. Allerdings sieht das nicht nach einer kritischen Stelle hinsichtlich der Performance und des Speichers aus

[/me]

Code: Alles auswählen

current = ['a', 'b', 'c']
filler = '.'
new = []
for element in current:
    new.extend([element, filler])

new
['a', '.', 'b', '.', 'c', '.']

Zuerst einmal: new zu überschreiben ist ein ziemlich blöder Einfall.

Um den Code jetzt mal etwas einfacher zu gestalten:

Code: Alles auswählen

current = ['a', 'b', 'c']
filler = '.'
data = [_ for _ in filler.join(current)]

[Xynon1]

Ich würde noch

Code: Alles auswählen

data = [_ for _ in filler.join(current)]

durch

Code: Alles auswählen

data = list(filler.join(current))

ersetzen.

[BlackJack]

@/me: Was spricht dagegen den Namen `new` zu verwenden? Das ist der Name eines Moduls aus der Standardbibliothek (Python <3), welches schon ziemlich lange komplett "deprecated" ist. Ich würde eher beanstanden wenn jemand tatsächlich das Modul importiert und verwendet. In dem Sinne ist der Name also "frei".

[deets]

Um den Code jetzt mal etwas einfacher zu gestalten:

Code: Alles auswählen

current = ['a', 'b', 'c']
filler = '.'
data = [_ for _ in filler.join(current)]

Xynon1 hat ja schon gesagt, wie das schoener geht. Ich wollte nur noch kurz anmerken, dass _ in Python "reserviert" ist, und zwar fuer Namen, die man eben *nicht* braucht. Also, wer zb ein Tupel auspackt, und dabei nur bestimmte indizes braucht, der benutzt _:

Code: Alles auswählen

a, _, b, c, _ = xrange(5)

Darum sollte man nicht einfach so underscore verwenden.

[Xynon1]

Code: Alles auswählen

a, _, b, c, _ = xrange(5)

Das ist keine gutes Beispiel dafür, du machst ja sonst auch nicht

Code: Alles auswählen

a, d, b, c, d = xrange(5)

[BlackJack]

@Xynon1: Doch das ist ein gutes Beispiel dafür. Es ist ja egal das der Name zweimal gebunden wird, weil man ihn ja eben nicht braucht. Und dafür macht es keinen Sinn irgendwelche zusätzlichen Namen zu erfinden und damit den Namensraum zuzumüllen. Ich benutze oft den Namen `dummy` für Sachen die ich benennen muss, aber eigentlich nicht benötige, und da schreibe ich dann auch so etwas wie ``a, dummy, b, c, dummy = xrange(5)`` wenn es sein muss.

[Xynon1]

Ok, macht Sinn, ich nehm des öfter "tmp".
Aber meist benutze ich dennoch einen vernünpftigen Namen, auch wenn ich ihn nicht brauche.

[deets]

@Xynon

Und wenn du dann sowas wie pylint oder pychecker benutzt, dann meckert der Aber _ oder _foo eben nicht - und das ist auch recht praktisch, auch fuer nicht genutzte Parameter usw.

[Xynon1]

Naja, stört in Funktionen nicht wirklich wenn man die Variable nun nicht nutzt. Im Hauptprogramm stimme ich zu das es dort sehr Sinnvoll ist, aber für nicht genutzte Parameter finde ich das unsinnig. Schließlich gibt es doch in Python default-Parameter und selbst wenn das nicht zum tragen kommt übergebe ich lieber ein None, "" oder 0. Bringt das irgendeinen Vorteil _ zu übergeben?

[mutetella]

@/me:
Genau das hab' ich gesucht!! Danke. Bei string-Methoden hätte ich jetzt doch nie geschaut...
Auch wenn ich jetzt gleich wieder einen Anpfiff kassiere: Nach meinem Gefühl sollte 'join' eher eine tuple-Methode sein. So in der Art

Code: Alles auswählen

['a', 'b', 'c'].join('.')
['a', '.', 'b', '.', 'c']

Gruß
mutetella

[DasIch]

Das ist kein tuple, das ist eine Liste und ''.join() funktioniert momentan mit allen iterables. Für alle iterables join zu implementieren ist etwas umständlich.

[mutetella]

Ja, sorry, natürlich list, könnte auf einem tuple auch nicht funktionieren .
Für alle iterables wäre ja auch überhaupt nicht möglich und IMHO nicht nötig.
Ich kann mich täuschen, aber außer auf Listen würde das doch sowieso nicht klappen, außer ein neues Objekt würde zurückgegeben...

Je mehr ich darüber nachdenke: 'join' ist wohl als string-Methode doch ganz gut untergebracht...

[BlackJack]

@Xynon1: Es geht nicht darum `_` oder `_foo` zu übergeben sondern entgegen zu nehmen. Das heisst man schreibt Funktionen die bestimmte Parameter entgegen nehmen, die aber nie verwenden. Und da ist es eben ganz nett, dass man diese kennzeichnen kann, damit der Leser nicht sucht wo es denn nun verwendet wird und gleichzeitig weiss, dass es Absicht ist und kein versehen.

[deets]

Ja, sorry, natürlich list, könnte auf einem tuple auch nicht funktionieren .
Für alle iterables wäre ja auch überhaupt nicht möglich und IMHO nicht nötig.
Ich kann mich täuschen, aber außer auf Listen würde das doch sowieso nicht klappen, außer ein neues Objekt würde zurückgegeben...

Natuerlich ist es fuer alle iterables moeglich (sofern sie strings zurueckgeben in jedem Element).

Und so funktioniert auch sowas hier (auf nicht-listen und nicht-tupeln:

Code: Alles auswählen

print "|".join("abcde")
print ";".join(dict(a="foo", b="bar"))

Und ob es noetig ist? Na, nix ist "noetig", aber konsistent und nuetzlich so manches.

[Xynon1]

@BlackJack
Werde ich mir merken. Klang halt nur komisch

auch fuer nicht genutzte Parameter usw.

Parameter sind für mich, die Variablen die im Kopf der Funktion definiert werden und nicht die Rückgabewerte welche ich erhalte.

[BlackJack]

@Xynon1: Ich habe ein bisschen die Befürchtung wir reden aneinander vorbei. Parameter sind für mich genau das selbe. Und genau da kann ein (führender) `_` nützlich sein um dem Leser klar zu machen, dass man einen davon innerhalb der Funktion absichtlich nicht verwendet. Also auch nicht einen Default-Wert sondern *gar nicht*. Typisches Beispiel sind Callback-Funktionen die eine bestimmte Anzahl von Argumenten entgegen nehmen müssen, bei denen man aber nicht alle braucht.