Das deutsche Python-Forum

Hallo.

Ich bekomme aus einer Exec-Funktion Parameter geliefert.
Dies kann entweder ein String sein (nur ein Wert) oder ein Tuple (wenn mehrere Werte übergeben werden).
Ich habe keinen Einfluß darauf, ob ein String oder ein Tuple bei mir ankommt.
Nun sollen die erhaltenen Werte an eine Liste angehängt werden.
Bei String ist mir klar wie.
Aber was mache ich wenn ein Tuple kommt ?

if TUPLE .... ?
Oder gibt es was Integriertes ?

Danke für's Mitdenken.


MrNiceTry

MrNiceTry hat geschrieben:Nun sollen die erhaltenen Werte an eine Liste angehängt werden.
Bei String ist mir klar wie.
Aber was mache ich wenn ein Tuple kommt ?

Ein Tuple kann man so erkennen:
Aber schön ist das nicht, weil du so keine Listen erkennst die du genauso verarbeiten könntest.
Andersrum hat man das Problem bei unicode/string.

Daher würde mich auch mal interessieren wie man das sauber unterscheiden kann.

Gruß
sparrow

Hallo,

wenn man sowas überhaupt explizit überprüfen möchte, würde man mMn eher isinstance() nutzen:
Das geht dann auch für Tuple.

Besten Gruß,

brb

Barabbas hat geschrieben:wenn man sowas überhaupt explizit überprüfen möchte, würde man mMn eher isinstance() nutzen:

Code: Alles auswählen

>>> isinstance([123,456], (list, tuple))
True

Supi, das ist eine tolle Lösung.

Wie wäre es denn für den Threadersteller ohne explizite Prüfung möglich sein Vorhaben umzusetzen?

Hallo,

die Frage habe ich mir auch gestellt. Wenn dir die Schnittstelle sowohl Strings als auch Tuples liefert, scheint nicht viel anderes übrig zu bleiben, als zu überprüfen, ob die jeweiligen Daten jetzt Strings oder Tuples sind.
Meine vorsichtige Formulierung bezog sich in diesem Fall also weniger darauf, dass ich eine bessere Lösung parat hätte, als darauf, dass ich betonen wollte, dass man nach Möglichkeit versucht, sowas zu vermeiden (Stichwort "Duck Typing"). Da Strings und Tuple aber letztlich jeweils Iterables sind, scheint mir dieser Ansatz in diesem Fall nicht sonderlich fruchtbar. Aber ich lasse mich da gerne belehren, ich mache mir ja auch nur meine Gedanken .

Besten Gruß,

brb

//edit: Nur um zu klären, wie ich das mit den Iterables meinte: Wenn man beispielsweise nicht zwischen Strings und Tuples, sondern zwischen Ints und Tuples unterscheiden müsste, könnte man statt eines expliziten Typ-Vergleichs folgendes machen:
Das wäre in so weit eine generischere Vorgehensweise, als dass alle Objekte, die __getitem__ oder __iter__ implementieren korrekt mit extend() in die Liste aufgenommen würden. Die Objekte, die diese Methoden nicht implementieren, würden aber zunächst einen TypeError werfen und dann ganz normal mit append() in die Liste aufgenommen werden.

Aber wie gesagt: Für den TE kommt diese Vorgehensweise so nicht in Frage, weil eben sowohl Strings als auch Tuples Iterables sind und somit über extend() aufgenommen werden. Die Strings dann aber Zeichen für Zeichen - was ja in diesem Fall nicht erwünscht sein dürfte.

Ich könnte mir sowas vorstellen:

Was haben denn alle gegen isinstance? (bis auf Barabbas ) Wobei man sinnvoller Weise wohl eher auf "tuple" testen würde; eine Funktion liefert ja irgend ein Objekt, oder ein Tupel von Objekten.

Ich würde auch sagen, dass die API an der Stelle einfach unschön ist. Um das "duck typing" möglichst wenig zu beeinträchtigen würde ich übrigens auf die Zeichenkette prüfen und nicht auf das Tupel. In der Praxis "erfinden" die Leute nämlich eher eigene, iterierbare Containertypen statt Zeichenketten abzuleiten. Ungetestet:
@mutetella: Wenn schon dann gleich komplett in einer Zeile und ohne Namen zu wiederholen:

@BlackJack: Das ist cool, auf sowas steh' ich...
Danke!

Und isinstance() ist natürlich auch schöner als type(). Wenn man über Typprüfung nachdenkt, dann drängt sich halt dieses 'type' auf...

mutetella

BlackJack hat geschrieben:Ich würde auch sagen, dass die API an der Stelle einfach unschön ist. Um das "duck typing" möglichst wenig zu beeinträchtigen würde ich übrigens auf die Zeichenkette prüfen und nicht auf das Tupel. In der Praxis "erfinden" die Leute nämlich eher eigene, iterierbare Containertypen statt Zeichenketten abzuleiten.

Das ist meiner Meinung nach tatsächlich der einzig sinnvolle Weg.

Hat man etwas, das entweder ein () oder ein [] ist, und man will testen, was was ist, ohne isinstance zu benutzen (was der naheliegende Weg wäre) fällt mir folgendes ein: Stefan