Ach ja für strings if type(l) == str oder from types import StringType if type(l) == StringType -- Benjamin Kaminski mailto:bekaminski@gmail.com ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
--On 15. Dezember 2005 14:57:31 +0100 Benjamin Kaminski <BeKaminski@web.de> wrote:
Ach ja für strings
if type(l) == str
oder
from types import StringType if type(l) == StringType
type() verwendet man schon seit Ewigkeiten nicht mehr. isinstance() ist heute übliche Methode. -aj _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On Thu, 15 Dec 2005 15:03:12 +0100, Andreas Jung <lists@andreas-jung.com> wrote:
type() verwendet man schon seit Ewigkeiten nicht mehr. isinstance() ist heute übliche Methode.
Seit Ewigkeiten, aha. Warum? Und wer sagt das? -- Franz Steinhaeusler _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
--On 15. Dezember 2005 15:44:08 +0100 Franz Steinhaeusler <franz.steinhaeusler@gmx.at> wrote:
Warum? Und wer sagt das?
Ich. isinstance() gibt es seit Python 2.0 (oder sogar schon früher). Seit dem gibt es keinen Grund noch type() zu verwenden. Einige Vorteile wurden bereits erwähnt. Alleine von der visuelle Eindruck spricht für sich if type(foo) == type([]) or type(foo) == type(()): vs. if instance(foo, (tuple, list)): Wer heute noch mit type() programmiert hat einfach seit Jahren nicht mehr in das News-File von Python geschaut :-) Cheers, -aj _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On Thu, 15 Dec 2005 16:08:22 +0100, Andreas Jung <lists@andreas-jung.com> wrote:
--On 15. Dezember 2005 15:44:08 +0100 Franz Steinhaeusler <franz.steinhaeusler@gmx.at> wrote:
Warum? Und wer sagt das?
Ich. isinstance() gibt es seit Python 2.0 (oder sogar schon früher). Seit dem gibt es keinen Grund noch type() zu verwenden. Einige Vorteile wurden bereits erwähnt. Alleine von der visuelle Eindruck spricht für sich
if type(foo) == type([]) or type(foo) == type(()):
vs.
if instance(foo, (tuple, list)):
Wer heute noch mit type() programmiert hat einfach seit Jahren nicht mehr in das News-File von Python geschaut :-)
Ok, danke für die Erläuterung. In der Python doku steht noch: """ The isinstance() built-in function is recommended for testing the type of an object. """ -- Franz Steinhaeusler _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Warum muß man überhaupt wissen, ob etwas eine Liste ist? Reicht es nicht in 99% der Fälle aus, daß es iterierbar ist? Und das kann man testen: def isIterable(x): try: x=iter(x) except: pass else: return 1 try: for i in x: return 1 # iterable else: return 1 # iterable, although empty except: return 0 def isStringLike(x): """ ist x etwas wie ein String?? """ try: x+'' except TypeError: return 0 else: return 1 Das ganze hat Martellibot irgendwann mal in c.l.p. veröffentlicht ... und das ganze hilft, wenn man die Liste/ das Tupel durch irgendwas iterierbares ersetzen möchte. Macht das Programm um KLASSEN flexibler Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Reinsburgstraße 202b 70197 Stuttgart 0173/9409607 _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Harald Armin Massa wrote:
Warum muß man überhaupt wissen, ob etwas eine Liste ist?
Es kommt oft vor, dass man zwischen Liste (von Strings) und String unterscheiden möchte; i.d.R. gilt ein Stringargument dann gleichwertig mit "Liste bestehend nur aus dem String". Etwa in der Art def process(thing): for text in thing: output(text) Wenn jetzt thing ein String ist, "funktioniert" der Algorithmus immernoch - ruft aber output() für jedes einzelne Zeichen aus. In diesem Fall sollte man "ist string" testen, und nicht "ist liste": auch wenn es Tupel oder sonst eine Folge ist, will man die Elemente ausgeben. M.E. richtig lautet die Funktion def process(thing): if isinstance(thing, basestring): output(text) return for text in thing: output(text) D.h. der Test sollte nicht lauten if type(thing) == str weil das keine Unicode-Strings erkennt; if type(thing) in (str, unicode): hat den gleichen Effekt, ist aber vielleicht etwas langsamer. Ciao, Martin _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Am 15.12.2005 16:08:22 schrieb Andreas Jung:
Ich. isinstance() gibt es seit Python 2.0 (oder sogar schon früher). Seit dem gibt es keinen Grund noch type() zu verwenden. Einige Vorteile wurden bereits erwähnt. Alleine von der visuelle Eindruck spricht für sich
if type(foo) == type([]) or type(foo) == type(()):
vs.
if instance(foo, (tuple, list)):
Ähm ohne mich in die Diskussion type vs isinstance einmischen zu wollen, aber der visuelle Eindruck ist kein Argument, weil: if type(foo) in (list, tuple): funktioniert 1. wunderbar und sieht 2. in meinen Augen besser als die instance-Variante aus. Wobei das "besser-aussehen" nur eine Frage der Gewöhnung ist.
Wer heute noch mit type() programmiert hat einfach seit Jahren nicht mehr in das News-File von Python geschaut :-)
cu boesi, der auch weiter type verwenden wird... -- Ein sicherer Rechner steht ohne Netz und Strom in einem Schweizer Kellersafe, die Schwiegermutter hält mit dem Nudelholz Wache vor der Kellertüre ... Und sicher sind die Daten trotzdem nicht ... _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Alexander 'boesi' =?ISO-8859-1?Q?B=F6secke?= <boesi.josi@gmx.net> kritzelte:
if type(foo) in (list, tuple):
funktioniert 1. wunderbar
Fuer kleine Werte von `funktioniert` und infinitesimale Werte von `wunderbar`. Das erstemal wenn ein Objekt einer Klasse class listx(list) : # whatever daherkommt, geht der type-Vergleich in die Hose. -- Christian Tanzer http://www.c-tanzer.at/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Jetzt will ich doch noch mal meinen Senf dazugeben. Am 15.12.2005 17:57:03 schrieb tanzer@swing.co.at:
if type(foo) in (list, tuple):
funktioniert 1. wunderbar
Fuer kleine Werte von `funktioniert` und infinitesimale Werte von `wunderbar`.
Das erstemal wenn ein Objekt einer Klasse
class listx(list) : # whatever
daherkommt, geht der type-Vergleich in die Hose.
Ja natuerlich, muss ja auch so sein. type liefert den Typ eines Objekts und isinstance überprüft ob ein Objekt von einem bestimmten Typ abgeleitet (instanziert) ist. Das sind fuer mich erstmal 2 grundverschiedene Dinge, auch wenn sich die Einsatzgebiete haeufig ueberschneiden. Der Typ des Objektes einer Klasse 'listx' ist nunmal 'listx' und nicht 'list'. Gerade bei den eingebauten Datentypen sehe ich allgemein als grossen Vorteil zu wissen, ob ein Objekt 'list' oder 'listx' als Ursprung hat. Weil bei 'list' als Datentyp kann ich mich auf ein bestimmtes Verhalten verlassen, 'listx' kann dagegen kann so ziemlich alles sein.[*] Wenn ich bei type einen unbekannten Datentyp zurueckbekomm, kann ich ja noch mit issubclass testen, ob der Typ von list abgeleitet wurde. cu boesi [*] Natuerlich ist es richtig mieser Stil, 'listx' so zu verunstalten, dass es sich nicht mehr wie 'list' verhaelt. -- |¯|/¯/¯¯¯\|¯| |¯|¯| |¯|/¯/¯¯¯\|¯¯¯¯\|¯¯¯¯ http://| / / /¯\ | | | | | | / / /¯\ | (¯) | |¯¯ smb://| \ \ \_/ | `¯´ | |__| \ \ \_/ | ¯ /| ¯| ftp://|_|\_\___/|_|¯|_|____|_|\_\___/|_|¯¯ |_|¯ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Am 17.12.2005 20:45:38 schrieb Alexander 'boesi' Bösecke:
Der Typ des Objektes einer Klasse 'listx' ist nunmal 'listx' und nicht 'list'. Gerade bei den eingebauten Datentypen sehe ich allgemein als grossen Vorteil zu wissen, ob ein Objekt 'list' oder 'listx' als Ursprung hat. Weil bei 'list' als Datentyp kann ich mich auf ein bestimmtes Verhalten verlassen, 'listx' kann dagegen kann so ziemlich alles sein.[*]
Ich hab grad festgestellt, man ja auch 'listx' keine Methoden "klauen" (im Sinne von loeschen) kann. Da man Methoden aber sehr wohl aendern kann, bleibt das Problem prinzipiell bestehen. Wenn ich ein Objekt auf einen selbst definierten Datentyp testen will, besteht dieses Problem zwar auch. Aber bei derartigen Objekten kann ich nur aus dem Datentyp ja auf gar kein Verhalten schliessen [*] cu boesi [*] ausser in einer vertrauenswürdigen Umgebung, aber da relativiert sich das ganze sowieso. -- --==SECURITY ALERT==-- Your Computer Is Currently Broadcasting An Internet IP Address. With This Address, Someone Can Begin Attacking Your Computer. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Benjamin Kaminski schrieb:
Ach ja für strings if type(l) == str oder from types import StringType if type(l) == StringType
isinstance() ist eigentlich immer die bessere Wahl, da es Subklassen zulässt. Ansonsten würde ich bei dem Test oben den Vergleich mit 'is' verwenden. Manchmal ist auch duck-typing vorzuziehen. Dann kann man einfach mal nachschauen, wie sich die Typen unterscheiden:
dir([]) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delslice__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__setslice__', '__str__', 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
dir('') ['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__', '__str__', 'capitalize', 'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs', 'find', 'index', 'isalnum', 'isalpha', 'isdigit', 'islower', 'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'replace', 'rfind', 'rindex', 'rjust', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
Bestimmte Methoden und Attribute sind spezifisch für bestimmte 'Meta'-Typen (wie Sequenzen, etc). Siehe dazu auch http://docs.python.org/lib/types.html Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (8)
-
"Martin v. Löwis" -
Alexander 'boesi' Bösecke -
Andreas Jung -
Benjamin Kaminski -
Franz Steinhaeusler -
Harald Armin Massa -
Stefan Behnel -
tanzer＠swing.co.at