Guido van Rossum <[EMAIL PROTECTED]> added the comment: > Well, okay. I still think we should expose these core interpreter types > somehow, so people can identify types easily. I don't want to be forced > to finding the type of sys._getframe to tell if I have a frame object on > my hands. Where would you put them?
Perhaps that one belongs together with sys._getframe? You don't seem to be getting my point (or you are purposely ignoring it), and this is frustrating for me. If these types must be exposed they should be each be exposed in a a module (new or existing) that defines other objects (types, functions, constants, what have you) with a related purpose. So maybe dict views etc. can be in collections. And maybe module, function, class, properties, some standard decorators (classmethod, staticmethod) and various types of methods and method wrappers can be in a module that packages code structures. OTOH code, frame, traceback may be more suitable for a low-level module (although I'm not sure about traceback, perhaps it is closer exceptions). Many types of iterators may best be placed in itertools (which defines them in the first place, many operations there already *are* their own type). But the iterators over the built-in collection types (list, dict etc.) should probably live in collections again. You see, coming up with a meaningful grouping is not all that easy -- but that's no reason to lump them all together in a "built-in-types" module. Another criterion for grouping is whether the types make sense for other implementations like Jython, IronPython or PyPy, or not. I'm all for exposing these. But I'm 100% against just collecting all those types and putting them in a single grab-bag module. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1605> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
