Hallo! Wie ich gerade sehe, gibt es weder in Python 2.4 noch in 2.5 die Variablen types.SetType (bzw. types.FrozensetType), was mich doch ein wenig erstaunt. Man kann sie zwar selbst auf type(set()) (bzw. type(frozenset()) setzen, aber noch fehlt mir ein furchtbar intelligenter Grund da- fuer, warum das jeder fuer sich tun sollte...? Gruss, Dinu -- Dinu C. Gherman ...................................................................... I love my Mac. I just wish it came in green! - www.greenmyapple.com
Dinu Gherman schrieb:
Hallo!
Wie ich gerade sehe, gibt es weder in Python 2.4 noch in 2.5 die Variablen types.SetType (bzw. types.FrozensetType), was mich doch ein wenig erstaunt.
Man kann sie zwar selbst auf type(set()) (bzw. type(frozenset()) setzen, aber noch fehlt mir ein furchtbar intelligenter Grund da- fuer, warum das jeder fuer sich tun sollte...?
Sollst du ja gar nicht:
print type(set()) == set True
Diez
Diez B. Roggisch:
print type(set()) == set True
Das ist nicht der Punkt. Das Modul types gibt es eben darum, damit ich so etwas nicht immer schreiben muss (wie bei den leidigen Tests in der Art if type(obj) == type(""): ...). Im Moment scheint mir, als ob types.SetType einfach "vergessen" worden waere... Dinu
Dinu Gherman schrieb:
Diez B. Roggisch:
print type(set()) == set True
Das ist nicht der Punkt. Das Modul types gibt es eben darum, damit ich so etwas nicht immer schreiben muss (wie bei den leidigen Tests in der Art if type(obj) == type(""): ...).
Im Moment scheint mir, als ob types.SetType einfach "vergessen" worden waere...
Aber es sind doch alle Konstruktoren die typen: type('') == str => True type(10) == int => True und so weiter. Das Modul types selbst ist unnoetig. Diez
Diez B. Roggisch:
Aber es sind doch alle Konstruktoren die typen:
type('') == str => True type(10) == int => True
und so weiter.
Kurze Antwort: Du meinst wahrscheinlich Datentypen. Tatsaechlich gibt es Typen fuer alles Moegliche, Frames, Funktionen, sogar den Typ NotImplemented. Wenn man ein Programm schreibt, dass mit *allen* Typen zurechtkommen muss (von mir aus z.B. einen Debugger), dann moechte man eine uniforme Methode fuer die Typ-Pruefung verwenden. Ich dachte, dafuer waere das types-Modul geeignet.
Das Modul types selbst ist unnoetig.
Ich finde, der Typ String ist streng genommen auch unnoetig und koennte durch Unicode allein ersetzt werden. Aber Python ist keine akademisch- theoretisch-saubere Sprache. Gruss, Dinu
Hallo, On Sat, 10 Feb 2007 19:24:13 +0100 Dinu Gherman <gherman@darwin.in-berlin.de> wrote:
Ich finde, der Typ String ist streng genommen auch unnoetig und koennte durch Unicode allein ersetzt werden. Aber Python ist keine akademisch- theoretisch-saubere Sprache. Ja, in Python 3.0 wird ja auch str durch Unicode ersetzt werden - es kommt lediglich ein bytes()-Typ hinzu, den man verwenden kann wenn Unicode mal grade stört.
grüße, Marek
Dinu Gherman schrieb:
Wenn man ein Programm schreibt, dass mit *allen* Typen zurechtkommen muss (von mir aus z.B. einen Debugger), dann moechte man eine uniforme Methode fuer die Typ-Pruefung verwenden. Ich dachte, dafuer waere das types-Modul geeignet.
Seit Python 2.2 gibt es bessere Möglichkeiten als das types-Modul; deshalb wird es auch nicht systematisch um neue Typen erweitert (sondern besteht nur noch aus Rückwärtskompatibilität). Ciao, Martin
Am Freitag, 9. Februar 2007 schrieb Diez B. Roggisch:
Dinu Gherman schrieb:
Diez B. Roggisch:
print type(set()) == set
True
Das ist nicht der Punkt. Das Modul types gibt es eben darum, damit ich so etwas nicht immer schreiben muss (wie bei den leidigen Tests in der Art if type(obj) == type(""): ...).
Im Moment scheint mir, als ob types.SetType einfach "vergessen" worden waere...
Aber es sind doch alle Konstruktoren die typen:
type('') == str => True type(10) == int => True
und so weiter.
Das Modul types selbst ist unnoetig.
Hmm, nicht ganz, in "hot paths" kann es der Performance zuträglich sein, wenn man sich eine der Evaluierungen spart: if type(obj) == types.StringType: ... Pete
Hi Pete,
Hmm, nicht ganz, in "hot paths" kann es der Performance zuträglich sein, wenn man sich eine der Evaluierungen spart: if type(obj) == types.StringType: ...
Aber ist type(obj) == str denn wirklich langsamer? Es wird erst lokal aufgeloest, danach global - genauso wie modulnamen, oder nicht? Womit der lookup direkt gelingt, wohingege ja noch "StringType" in types aufgeloest werden muss. Diez
Hallo Hans-Peter, Hallo Diez, On 2007-02-12 13:36, Diez B. Roggisch wrote:
Hmm, nicht ganz, in "hot paths" kann es der Performance zuträglich sein, wenn man sich eine der Evaluierungen spart: if type(obj) == types.StringType: ...
ich glaube, Python wäre nicht Python, wenn das für die Aufname eines SetType in types eine Rolle spielen würde. ;-)
Aber ist
type(obj) == str
denn wirklich langsamer? Es wird erst lokal aufgeloest, danach global - genauso wie modulnamen, oder nicht? Womit der lookup direkt gelingt, wohingege ja noch "StringType" in types aufgeloest werden muss.
Wozu vermuten, wenn man messen kann? :-) Folgende Messwerte sind mit Python 2.5 bestimmt. Es geht mir nur um die Relationen, deshalb verzichte ich auf die Angabe von Rechnerdaten. Der Rechner war während der Messungen bei ca. 0 % Auslastung, abgesehen natürlich von den Messungen selbst. python /usr/lib/python2.5/timeit.py -r 10 -s "import types; o = ''" "type(o) == types.StringType" (bzw. anderer Code entsprechend eingesetzt) Den timeit-Lauf habe ich jeweils mehrmals wiederholt und, wie in der Doku empfohlen, den kleinsten Wert genommen. type(o) == types.StringType 0.571 usec type(o) is types.StringType 0.523 usec type(o) == str 0.449 usec type(o) is str 0.405 usec isinstance(o, types.StringType) 0.519 usec isinstance(o, str) 0.412 usec Der Vergleich mit "is" ist erwartungsgemäß schneller als mit "==", da nur ein Zeiger-Vergleich durchgeführt werden muss. "isinstance(o, str)" ist praktisch genau so schnell wie "type(o) is str". In den meisten Fällen will man wohl die abgeleiteten Klassen mit erwischen, so dass aus meiner Sicht auch unter dem Geschwindigkeits-Aspekt nichts gegen isinstance spricht. Lookups abkürzen ---------------- Ich habe auch getestet, wie sich die Erstellung eines Namens im lokalen Namensraum auswirkt. python /usr/lib/python2.5/timeit.py -r 10 -s "from test import str_global" "str_global()" mit def str_global(): o = "" for i in xrange(1000): isinstance(o, str) def str_lokal(): lstr = str o = "" for i in xrange(1000): isinstance(o, lstr) str_global 433 usec str_lokal 371 usec Man kann das "Nachschlagen" des str-Typs durch Anlegen eines lokalen Alias-Namens also potenziell deutlich beschleunigen. Abschließend möchte ich darum bitten, nicht zu Tempo-Fanatikern zu werden; die meisten Tuning-Maßnahmen sind wohl unnötig. :-) In den obigen Beispielen geht es um Laufzeiten von einer halben Millisekunde! Bei der Gelegenheit etwas "Eigenwerbung": http://sschwarzer.com/download/optimization_europython2006.pdf Beschleunigte Grüße ;-) Stefan
Dinu Gherman schrieb:
Das ist nicht der Punkt. Das Modul types gibt es eben darum, damit ich so etwas nicht immer schreiben muss (wie bei den leidigen Tests in der Art if type(obj) == type(""): ...).
Und ein dritter Versuch. Bei neuem Code solltest Du *weder* if type(obj) == type(""): schreiben, noch if type(obj) == types.StringType: *sondern* if type(obj) == str (u.U. auch if isinstance(obj, str): ) Ciao, Martin
Martin v. Löwis:
Und ein dritter Versuch. Bei neuem Code solltest Du *weder*
if type(obj) == type(""):
schreiben, noch
if type(obj) == types.StringType:
*sondern*
if type(obj) == str
(u.U. auch
if isinstance(obj, str):
)
Ok, ich zaehle meine Versuche nicht so systematisch, aber vielleicht kommt es mit einem Beispiel meinerseits besser rueber. Was muesste ich also in den folgenden Zeilen fuer ??? einsetzen, um die gewuenschte Ausgabe zu bekommen? obj = NotImplemented if type(obj) == ???: print "verstanden" if isinstance(obj, ???): print "verstanden" Ich vermute, die Antwort lautet: ??? = type(NotImplemented). Und das ist eben nichts anderes als "frueher" bei Code wie: if type(obj) == type(""). Mit anderen Worten: woher bekomme ich das NotImplementedType, ohne type(NotImplemented) benutzen zu muessen? Antwort: aus dem Modul types. Wenn es keine andere Moeglichkeit gibt, ist das Modul nicht ueberfluessig. Wenn dem so ist und kein SetType/FrozenSetType drin ist, be- trachte ich das types-Modul als unvollstaendig, weil es einen uniformen Zugriff auf alle Typen ueber diese Variablen nicht mehr ermoeglicht. Ob das tragisch ist, sei dahingestellt, aber es ist nicht konsistent und nicht elegant. Gruss, Dinu
Dinu Gherman schrieb:
Was muesste ich also in den folgenden Zeilen fuer ??? einsetzen, um die gewuenschte Ausgabe zu bekommen?
obj = NotImplemented
if type(obj) == ???: print "verstanden"
if isinstance(obj, ???): print "verstanden"
Ich vermute, die Antwort lautet: ??? = type(NotImplemented).
Korrekt. Was aber hat das mit SetType zu tun? (siehe Subject) In dem konkreten Fall würde ich aber if obj is NotImplemented: print "verstanden" schreiben: NotImplemented ist ein Singleton. Man schreibt ja auch if foo is None: anstelle von if isinstance(foo, types.NoneType)
Mit anderen Worten: woher bekomme ich das NotImplementedType, ohne type(NotImplemented) benutzen zu muessen?
Siehe oben: i.d.R. solltest Du nicht auf NotImplementedType testen, sondern auf NotImplemented.
Antwort: aus dem Modul types. Wenn es keine andere Moeglichkeit gibt, ist das Modul nicht ueberfluessig.
Mag sein. Du änderst aber das Thema: Deine ursprüngliche Frage war ja nach set und nicht nach NotImplementedType. Auch für den Test, den Du jetzt durchführen willst ("ist obj ein Exemplar von NotImplementedType") benötigt man das types-Modul nicht, weil NotImplemted ein Singleton ist.
Wenn dem so ist und kein SetType/FrozenSetType drin ist, be- trachte ich das types-Modul als unvollstaendig, weil es einen uniformen Zugriff auf alle Typen ueber diese Variablen nicht mehr ermoeglicht.
Es ist aber nicht der Zweck des types-Moduls, *alle* Typen zu enthalten. Es ist auch nicht realistisch anzunehmen, dass es das jemals könnte. Python-Bibliotheken können selber neue Typen definieren, aber selbst für die mit Python standardmäßig ausgelieferten Typen ist es nicht praktikabel, alle im types-Modul aufzuführen. Anbei eine Liste von Typen, die es in Python 2.5 gibt, aber nicht im types-Modul. Diese Liste ist nicht vollständig (schon weil es manche Typen nur auf manchen Systemen gibt).
Ob das tragisch ist, sei dahingestellt, aber es ist nicht konsistent und nicht elegant.
set und frozenset aufzunehmen würde es nicht konsistent machen. Es wäre tragisch, wenn es konsistent wäre, weil dann 'import types' praktisch die gesamte Python-Bibliothek importieren müsste. Ciao, Martin ('Carbon.File', 'Alias') ('Carbon.File', 'FInfo') ('Carbon.File', 'FSCatalogInfo') ('Carbon.File', 'FSRef') ('Carbon.File', 'FSSpec') ('MacOS', 'Error') ('_AE', 'AEDesc') ('_App', 'ThemeDrawingState') ('_CF', 'CFArrayRef') ('_CF', 'CFDataRef') ('_CF', 'CFDictionaryRef') ('_CF', 'CFMutableArrayRef') ('_CF', 'CFMutableDataRef') ('_CF', 'CFMutableDictionaryRef') ('_CF', 'CFMutableStringRef') ('_CF', 'CFStringRef') ('_CF', 'CFTypeRef') ('_CF', 'CFURLRef') ('_CG', 'CGContextRef') ('_CarbonEvt', 'EventHandlerCallRef') ('_CarbonEvt', 'EventHandlerRef') ('_CarbonEvt', 'EventHotKeyRef') ('_CarbonEvt', 'EventLoopRef') ('_CarbonEvt', 'EventLoopTimerRef') ('_CarbonEvt', 'EventQueueRef') ('_CarbonEvt', 'EventRef') ('_CarbonEvt', 'EventTargetRef') ('_Cm', 'Component') ('_Cm', 'ComponentInstance') ('_Ctl', 'Control') ('_Dlg', 'Dialog') ('_Drag', 'DragObj') ('_IBCarbon', 'IBNibRef') ('_List', 'List') ('_Menu', 'Menu') ('_Mlte', 'TXNFontMenuObject') ('_Mlte', 'TXNObject') ('_OSA', 'OSAComponentInstance') ('_Qd', 'BitMap') ('_Qd', 'GrafPort') ('_Qdoffs', 'GWorld') ('_Qt', 'IdleManager') ('_Qt', 'Media') ('_Qt', 'Movie') ('_Qt', 'MovieController') ('_Qt', 'SGOutput') ('_Qt', 'TimeBase') ('_Qt', 'Track') ('_Qt', 'UserData') ('_Res', 'Resource') ('_Snd', 'SPB') ('_Snd', 'SndChannel') ('_TE', 'TE') ('_Win', 'Window') ('__builtin__', 'CArgObject') ('__builtin__', 'Element') ('__builtin__', 'EncodingMap') ('__builtin__', 'MultibyteCodec') ('__builtin__', 'MultibyteIncrementalDecoder') ('__builtin__', 'MultibyteIncrementalEncoder') ('__builtin__', 'MultibyteStreamReader') ('__builtin__', 'MultibyteStreamWriter') ('__builtin__', 'StgDict') ('__builtin__', 'Struct') ('__builtin__', 'basestring') ('__builtin__', 'classmethod') ('__builtin__', 'deque_iterator') ('__builtin__', 'deque_reverse_iterator') ('__builtin__', 'enumerate') ('__builtin__', 'frozenset') ('__builtin__', 'iterparse') ('__builtin__', 'property') ('__builtin__', 'reversed') ('__builtin__', 'set') ('__builtin__', 'sqlite3Node') ('__builtin__', 'staticmethod') ('__builtin__', 'super') ('__builtin__', 'weakref') ('_csv', 'Dialect') ('_csv', 'Error') ('_csv', 'reader') ('_csv', 'writer') ('_ctypes', 'Array') ('_ctypes', 'ArrayType') ('_ctypes', 'CField') ('_ctypes', 'CFuncPtr') ('_ctypes', 'CFuncPtrType') ('_ctypes', 'PointerType') ('_ctypes', 'SimpleType') ('_ctypes', 'StructType') ('_ctypes', 'Structure') ('_ctypes', 'Union') ('_ctypes', 'UnionType') ('_ctypes', '_CData') ('_ctypes', '_Pointer') ('_ctypes', '_SimpleCData') ('_curses', 'error') ('_curses_panel', 'error') ('_hashlib', 'HASH') ('_lsprof', 'Profiler') ('_lsprof', 'profiler_entry') ('_lsprof', 'profiler_subentry') ('_random', 'Random') ('_sha256', 'sha224') ('_sha256', 'sha256') ('_sha512', 'sha384') ('_sha512', 'sha512') ('_testcapi', 'error') ('_types', 'Helper') ('array', 'array') ('audioop', 'error') ('autoGIL', 'AutoGILError') ('binascii', 'Error') ('binascii', 'Incomplete') ('bsddb', 'error') ('cPickle', 'BadPickleGet') ('cPickle', 'PickleError') ('cPickle', 'Pickler') ('cPickle', 'PicklingError') ('cPickle', 'UnpickleableError') ('cPickle', 'Unpickler') ('cPickle', 'UnpicklingError') ('cStringIO', 'StringI') ('cStringIO', 'StringO') ('codecs', 'BufferedIncrementalDecoder') ('codecs', 'BufferedIncrementalEncoder') ('codecs', 'CodecInfo') ('codecs', 'IncrementalDecoder') ('codecs', 'IncrementalEncoder') ('collections', 'defaultdict') ('collections', 'deque') ('copy', 'Error') ('ctypes', 'ArgumentError') ('datetime', 'date') ('datetime', 'datetime') ('datetime', 'time') ('datetime', 'timedelta') ('datetime', 'tzinfo') ('dbm', 'error') ('distutils.errors', 'CCompilerError') ('distutils.errors', 'CompileError') ('distutils.errors', 'DistutilsArgError') ('distutils.errors', 'DistutilsClassError') ('distutils.errors', 'DistutilsError') ('distutils.errors', 'DistutilsExecError') ('distutils.errors', 'DistutilsFileError') ('distutils.errors', 'DistutilsGetoptError') ('distutils.errors', 'DistutilsInternalError') ('distutils.errors', 'DistutilsModuleError') ('distutils.errors', 'DistutilsOptionError') ('distutils.errors', 'DistutilsPlatformError') ('distutils.errors', 'DistutilsSetupError') ('distutils.errors', 'DistutilsTemplateError') ('distutils.errors', 'LibError') ('distutils.errors', 'LinkError') ('distutils.errors', 'PreprocessError') ('distutils.errors', 'UnknownFileError') ('dl', 'error') ('encodings', 'CodecRegistryError') ('encodings.ascii', 'IncrementalDecoder') ('encodings.ascii', 'IncrementalEncoder') ('exceptions', 'ArithmeticError') ('exceptions', 'AssertionError') ('exceptions', 'AttributeError') ('exceptions', 'BaseException') ('exceptions', 'DeprecationWarning') ('exceptions', 'EOFError') ('exceptions', 'EnvironmentError') ('exceptions', 'Exception') ('exceptions', 'FloatingPointError') ('exceptions', 'FutureWarning') ('exceptions', 'GeneratorExit') ('exceptions', 'IOError') ('exceptions', 'ImportError') ('exceptions', 'ImportWarning') ('exceptions', 'IndentationError') ('exceptions', 'IndexError') ('exceptions', 'KeyError') ('exceptions', 'KeyboardInterrupt') ('exceptions', 'LookupError') ('exceptions', 'MemoryError') ('exceptions', 'NameError') ('exceptions', 'NotImplementedError') ('exceptions', 'OSError') ('exceptions', 'OverflowError') ('exceptions', 'PendingDeprecationWarning') ('exceptions', 'ReferenceError') ('exceptions', 'RuntimeError') ('exceptions', 'RuntimeWarning') ('exceptions', 'StandardError') ('exceptions', 'StopIteration') ('exceptions', 'SyntaxError') ('exceptions', 'SyntaxWarning') ('exceptions', 'SystemError') ('exceptions', 'SystemExit') ('exceptions', 'TabError') ('exceptions', 'TypeError') ('exceptions', 'UnboundLocalError') ('exceptions', 'UnicodeDecodeError') ('exceptions', 'UnicodeEncodeError') ('exceptions', 'UnicodeError') ('exceptions', 'UnicodeTranslateError') ('exceptions', 'UnicodeWarning') ('exceptions', 'UserWarning') ('exceptions', 'ValueError') ('exceptions', 'Warning') ('exceptions', 'ZeroDivisionError') ('functools', 'partial') ('grp', 'struct_group') ('hotshot', 'ProfilerError') ('imageop', 'error') ('imp', 'NullImporter') ('itertools', '_grouper') ('itertools', 'chain') ('itertools', 'count') ('itertools', 'cycle') ('itertools', 'dropwhile') ('itertools', 'groupby') ('itertools', 'ifilter') ('itertools', 'ifilterfalse') ('itertools', 'imap') ('itertools', 'islice') ('itertools', 'izip') ('itertools', 'repeat') ('itertools', 'starmap') ('itertools', 'takewhile') ('itertools', 'tee') ('itertools', 'tee_dataobject') ('locale', 'Error') ('nis', 'error') ('operator', 'attrgetter') ('operator', 'itemgetter') ('parser', 'ParserError') ('posix', 'stat_result') ('posix', 'statvfs_result') ('resource', 'error') ('resource', 'struct_rusage') ('rgbimg', 'error') ('select', 'error') ('site', 'Quitter') ('site', '_Helper') ('site', '_Printer') ('socket', 'error') ('socket', 'gaierror') ('socket', 'herror') ('socket', 'sslerror') ('socket', 'timeout') ('sqlite3', 'Cache') ('sqlite3', 'Connection') ('sqlite3', 'Cursor') ('sqlite3', 'DataError') ('sqlite3', 'DatabaseError') ('sqlite3', 'Error') ('sqlite3', 'IntegrityError') ('sqlite3', 'InterfaceError') ('sqlite3', 'InternalError') ('sqlite3', 'NotSupportedError') ('sqlite3', 'OperationalError') ('sqlite3', 'PrepareProtocol') ('sqlite3', 'ProgrammingError') ('sqlite3', 'Row') ('sqlite3', 'Statement') ('sqlite3', 'Warning') ('sre_constants', 'error') ('string', 'Template') ('string', '_TemplateMetaclass') ('struct', 'error') ('termios', 'error') ('time', 'struct_time') ('warnings', '_OptionError') ('xml.parsers.expat', 'ExpatError') ('zipimport', 'ZipImportError') ('zipimport', 'zipimporter') ('zlib', 'error')
Martin v. Löwis:
[...]
Eine abschließende Bemerkung dazu von meiner Seite: In 2.5 sind types.GetSetDescriptorType und types.MemberDescriptorType neu, also kann das Modul nicht unnoetig oder veraltet sein. Mein Beispiel mit NotImplemented war nur ein Beispiel. Von externen Typen, auch sol- chen in der Standard-Bibliothek, war nie die Rede. Und dafuer, dass zwei, immerhin eingebaute, (Daten-) Typen (set/frozenset) in types nicht vorhanden sind, sehe ich weiterhin keinen anderen Grund als den, dass sie vergessen wurden. Gruss, Dinu
Und dafuer, dass zwei, immerhin eingebaute, (Daten-) Typen (set/frozenset) in types nicht vorhanden sind, sehe ich weiterhin keinen anderen Grund als den, dass sie vergessen wurden.
Darauf eine abschließende Antwort: Sei versichert, dass das nicht vergessen wurde, sondern absichtlich im types-Modul kein Alias angelegt wurde. Ich war dabei. Ein paar Belege dafür: - In PEP 348 heißt es (als Grund für die Ablehnung des PEPs): A centralized repository of type names was a mistake. Neither the "types" nor "new" modules should be carried forward to Python 3.0. Using two sets of names for the same objects is redundant and confusing. - http://mail.python.org/pipermail/python-dev/2002-May/024336.html OK, so let me explain why I'm against adding new stuff to types.py. I'm against adding new features to anything that's (about to) being deprecated. The addition of new features sends the wrong message: it suggests that the module is in active use, recommended for use, supported, maintained, etc. When someone finds that types.py has no name for the Boolean type, maybe this will cause them to realize that it's being deprecated and that in the long run (with emphasis on long) it's going away. Ciao, Martin
Hallo Dinu, On 2007-02-09 20:08, Dinu Gherman wrote:
Wie ich gerade sehe, gibt es weder in Python 2.4 noch in 2.5 die Variablen types.SetType (bzw. types.FrozensetType), was mich doch ein wenig erstaunt.
Man kann sie zwar selbst auf type(set()) (bzw. type(frozenset()) setzen, aber noch fehlt mir ein furchtbar intelligenter Grund da- fuer, warum das jeder fuer sich tun sollte...?
ich vermute, dass man inzwischen statt type(set()) einfach set verwenden sollte und statt type(frozenset()) nur frozenset: Python 2.4.3 (#1, Dec 29 2006, 02:22:42)
type(set()) is set True type(frozenset()) is frozenset True
Zum anderen stellt sich die Frage, was der Anwendungsfall für die Typprüfung ist. Wenn es die seltene emulierte Typprüfung mit isinstance ist, tut es problemlos etwas wie isinstance(value, set) . Dass noch so viele andere Typen im types-Modul rumliegen, die man analog zu oben bekommen kann, ist sicher eher der Kompatibilität alter Programme mit neueren Python-Versionen geschuldet. Andererseits gibt es ein paar Typen, die nicht in den Builtins vorhanden sind, z. B. module. Das kann man nur mit dem new-Modul relativ einfach erzeugen, soweit ich weiß. Wenn man also mit dem Modultyp vergleichen will, kann man isinstance(value, new.module) oder, wie ich gerade sehe, isinstance(value, types.ModuleType) verwenden. In Python 2.4.3 (s. o.) gilt jedenfalls Python 2.4.3 (#1, Dec 29 2006, 02:22:42)
new.module is types.ModuleType True
Viele Grüße Stefan
Dinu Gherman schrieb:
Wie ich gerade sehe, gibt es weder in Python 2.4 noch in 2.5 die Variablen types.SetType (bzw. types.FrozensetType), was mich doch ein wenig erstaunt.
Man kann sie zwar selbst auf type(set()) (bzw. type(frozenset()) setzen, aber noch fehlt mir ein furchtbar intelligenter Grund da- fuer, warum das jeder fuer sich tun sollte...?
Du musst, glaube ich, mal erklären, *warum* Du den Typ in dem Modul haben willst ("weil alle anderen Typen da auch drin sind" ist nicht überzeugend, weil das kein technischer Grund ist). Ursprünglich gab es das Modul types, um Code der Form if type(o) is types.ListType: schreiben zu können, später dann if isinstance(o, types.ListType): Nun scheint Deine Beschwerde zu sein, dass Du nicht if isinstance(o, types.SetType): schreiben kannst; Diez versucht Dir zu erklären, dass Du statt dessen *viel einfacher* if isinstance(o, set) schreiben kannst. Das ist einfacher, weil Du nicht auf das Modul types zugreifen musst. Nun hast Du offenbar entweder missverstanden, dass das builtin set bereits ein Typ *ist*, oder Du hast einen anderen Anwendungsfall. Ciao, Martin
Dinu Gherman schrieb:
Man kann sie zwar selbst auf type(set()) (bzw. type(frozenset()) setzen
Ich mache noch einen zweiten Versuch: Wenn Du types.SetType selber einführen wolltest, solltest Du *nicht* types.SetType = type(set()) schreiben, sondern types.SetType = set Weil: set *ist* bereits ein Typ. Ciao, Martin
participants (6)
-
"Martin v. Löwis" -
Diez B. Roggisch -
Dinu Gherman -
Hans-Peter Jansen -
Marek Kubica -
Stefan Schwarzer