This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author benjamin.peterson
Recipients benjamin.peterson, christian.heimes, gvanrossum
Date 2008-03-22.13:18:41
SpamBayes Score 0.157528
Marked as misclassified No
Message-id <>
In-reply-to <>
On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum <>

> Guido van Rossum <> 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.

I understand your point; I just didn't understand the extent that you want
to go to.

> 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.

It is indeed hard.

> 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 <>
> <>
> __________________________________
File name Uploaded
unnamed benjamin.peterson, 2008-03-22.13:18:39
Date User Action Args
2008-03-22 13:18:43benjamin.petersonsetspambayes_score: 0.157528 -> 0.157528
recipients: + benjamin.peterson, gvanrossum, christian.heimes
2008-03-22 13:18:41benjamin.petersonlinkissue1605 messages
2008-03-22 13:18:41benjamin.petersoncreate