New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pyvm module patch #45863
Comments
I've created a pyvm module for Python 3.0. So far it just contains a |
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' |
If there's a new "pyvm" module, there are a few things in sys that |
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 The list of types has grown pretty long and most of the types can't be ['PyCObject', '__doc__', '__name__', 'builtin_function', |
Well, it is already pretty cluttered -- it contains many items that
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 |
Guido van Rossum wrote:
I really think we should postpone the decision until after the next Christian |
There has been talk in the past of cleaning up the sys module by |
I've split the patch into two tasks. The first patch adds all types in The second patch contains the new pyvm.c module plus a modification to |
I like to apply the py3k_add_types_to_h.patch before the next alpha and |
Sure, go ahead and submit the uncontroversial part. |
Guido van Rossum wrote:
Applied py3k_add_types_to_h.patch in r59229 |
Could this be useful for the "make other Python implementors lives |
I'm afraid it's too late for this. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: