homepage

A while ago I've experimented with the pyvm module and a semi
auto-generated types list. The patch adds a script that reads
Include/*.h and adds all available PyTypeObjects to Modules/_typesmodule.c.
The patch or script may be useful in the future.

But what about static type objects that nevertheless may be exposed to
Python (e.g. dict_keyview?).

Guido van Rossum wrote:
> But what about static type objects that nevertheless may be exposed to
> Python (e.g. dict_keyview?).
I took care of the views a few weeks ago when I added all views and
iterators to the header files.
['PyCObject',
 'bool',
 'builtin_function_or_method',
 'bytearray',
 'bytearray_iterator',
 'bytes',
 'bytes_iterator',
 'callable_iterator',
 'cell',
 'classmethod',
 'classmethod_descriptor',
 'cmpwrapper',
 'code',
 'complex',
 'dict',
 'dict_itemiterator',
 'dict_items',
 'dict_keyiterator',
 'dict_keys',
 'dict_proxy',
 'dict_valueiterator',
 'dict_values',
 'enumerate',
 'float',
 'frame',
 'frozenset',
 'function',
 'generator',
 'getset_descriptor',
 'imp.NullImporter',
 'instancemethod',
 'int',
 'iterator',
 'list',
 'list_iterator',
 'list_reverseiterator',
 'longrange_iterator',
 'member_descriptor',
 'memoryview',
 'method',
 'method_descriptor',
 'module',
 'object',
 'property',
 'range',
 'range_iterator',
 'reversed',
 'set',
 'set_iterator',
 'slice',
 'sortwrapper',
 'staticmethod',
 'stderrprinter',
 'str',
 'str_iterator',
 'super',
 'traceback',
 'tuple',
 'tuple_iterator',
 'type',
 'wrapper_descriptor',
 'zip_iterator']

I think this is a really good idea. It's in stride with DRY, clean, and
sure beats the Python acrobatics that types currently does to find them.

I'm still resounding -1 on this.
Grouping types together because they happen to be implemented in C is a
silly thing to do. Groupings should be based on usage, not on
implementation style. I successfully argued against the inclusion of
all metaclasses in the abc.py module. This proposal would be even more
wrong. You might as well insist that all decorators need to be placed
in one module.

Okay. How about we use this like it is for 2.x, and split it out into
different modules in Py3k. We could have execution_types and core_types.

On Fri, Mar 21, 2008 at 3:03 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> Okay. How about we use this like it is for 2.x, and split it out into
> different modules in Py3k. We could have execution_types and core_types.
No.

> No
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?

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

On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum <report@bugs.python.org>
wrote:
>
> Guido van Rossum <guido@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@bugs.python.org>
> <http://bugs.python.org/issue1605>
> __________________________________
>

Is this ever likely to go anywhere? My understanding is that this would be difficult to do (or have I simply misread something?). If I'm correct, wouldn't it be better to use our limited resources elsewhere?

Well, the core issue is a disagreement on the way to go.
I would agree with Benjamin's and Christian's proposal, given that it's quite practical to implement. Guido's proposal means we would have to add new modules just so that the relevant C types can be exposed "at the right place".
The types module is generally used for low-level trickery (since most useful types are accessible from the builtin namespace), and IMO it makes sense to have a dedicated module for that.

I'm still against collecting all types in one module. Closing.