Ach ja für strings
if type(l) == str
oder
from types import StringType if type(l) == StringType
--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...
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.
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) : # whateverdaherkommt, 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.
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.
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