[issue1605] Semi autogenerated _types module

[Benjamin Peterson]

Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum <report at bugs.python.org>
wrote:

>
> Guido van Rossum <guido at python.org> 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 <report at bugs.python.org>
> <http://bugs.python.org/issue1605>
> __________________________________
>

Added file: http://bugs.python.org/file9810/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1605>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080322/2e60587a/attachment.txt