I've created a pyvm module for Python 3.0. So far it just contains a bunch of internal types. What methods do you like to add to pyvm? Somebody suggested internal functions from sys like the check internal.

Hm... What if we just put these names in sys?

I don't see it as an option. I'd rather keep the types in the 'types' module than to add them to the sys module.

If there's a new "pyvm" module, there are a few things in sys that should be moved there, I expect.

> I don't see it as an option. I'd rather keep the types in the 'types' > module than to add them to the sys module. Why such a strong opinion? 'sys' is pretty close to the VM too...

> Why such a strong opinion? 'sys' is pretty close to the VM too... sys is a very important and often used module, too. I don't like the idea to remove one module (types) and clutter an important module with its content. The list of types has grown pretty long and most of the types can't be instantiated in Python. I fear that the types are going to confuse too many people. However the types are useful for type checking and ABCs. ['PyCObject', '__doc__', '__name__', 'builtin_function', 'builtin_method', 'bytearray_iterator', 'bytes_iterator', 'callable_iterator', 'cell', 'classmethod_descriptor', 'cmpwrapper', 'code', 'dict_itemiterator', 'dict_items', 'dict_keyiterator', 'dict_keys', 'dict_valueiterator', 'dict_values', 'dictproxy', 'enumerate', 'frame', 'function', 'generator', 'getset_descriptor', 'instance_method', 'iterator', 'list_iterator', 'list_reverseiterator', 'longrange_iterator', 'member_descriptor', 'method_descriptor', 'module', 'range_iterator', 'reversed', 'set_iterator', 'sortwrapper', 'str_iterator', 'traceback', 'tuple_iterator', 'wrapper_descriptor']

> sys is a very important and often used module, too. I don't like the > idea to remove one module (types) and clutter an important module with > its content. Well, it is already pretty cluttered -- it contains many items that *I* don't recognize... :-) > The list of types has grown pretty long and most of the types can't be > instantiated in Python. I fear that the types are going to confuse too > many people. However the types are useful for type checking and ABCs. Stuff in sys that people don't use doesn't really confuse anyone IMO. I really don't think that this warrants a new module. Many of the datatype-related types (e.g. dict_keys) should not go there but in _collections anyway.

Guido van Rossum wrote: > Stuff in sys that people don't use doesn't really confuse anyone IMO. > > I really don't think that this warrants a new module. > > Many of the datatype-related types (e.g. dict_keys) should not go > there but in _collections anyway. I really think we should postpone the decision until after the next alpha. For now I like to commit the part of the patch that adds all types to the appropriate header files. A lot of internal types aren't available from other C files. Christian

There has been talk in the past of cleaning up the sys module by splitting it up into a package, although I don't know how that would work for a built-in module, though.

I've split the patch into two tasks. The first patch adds all types in Objects/ to the appropriate header files. I've renamed some types, too. The second patch contains the new pyvm.c module plus a modification to Modules/Setup.dist.

I like to apply the py3k_add_types_to_h.patch before the next alpha and discuss the fate of pyvm after the alpha.

> I like to apply the py3k_add_types_to_h.patch before the next alpha and > discuss the fate of pyvm after the alpha. Sure, go ahead and submit the uncontroversial part.

Guido van Rossum wrote: > Sure, go ahead and submit the uncontroversial part. Applied py3k_add_types_to_h.patch in r59229

Could this be useful for the "make other Python implementors lives easier" plan?

I'm afraid it's too late for this.