New features only go in future versions: Given the doc: "With a module, class or class instance object as argument (or anything else that has a __dict__ attribute), return that attribute." So you are proposing a change in the definition of vars() input.

I agree that the proposal is a good idea as far as it goes. Vars() predates __slots__ (introduced in 2.2). In particular, adding or deleting a __slots__ binding to a user-defined class should not change the behavior of vars().

I am thinking that the doc should also be tweaked a bit. It implies that all class instances have a __dict__ attribute. Before 2.2, when 'class' meant a user-defined old style class, that was true. But with 'types' becoming new-style classes, it is not.

Perhaps the domain of vars() should be extended to all objects, returning {} if nothing more. I may bring that idea to python-ideas list.

You should attach diffs (context diffs, I believe) rather than files so we can see what you changed. The diff module can create such. I believe your changes come after the following:

        d = PyObject_GetAttrString(v, "__dict__");
        if (d == NULL) {

The statement '''slots = PyObject_GetAttrString(v, "__slots__")''' gets the attribute from the object itself. Like most special attributes other than __dict__, it should be gotten from the object's class (or superclasses). [I don't know the C version of doing this.] For example, suppose v is a class with a custom metaclass and type(v).__slots__ == ('__slots__', '__init__') whereas v.__slots__ == ('a', 'b') (and v.__init__ is not assigned). Then vars(v) should return {'__slots__': ('__slots__', '__init__')}.

The comment /* Find attributes out of __slots__ */ seems misleading. I believe it should be /* Convert string to iterable of 1 string */

New code for 3.3 should use the new unicode api from pep 393. Though I could be wrong, I believe PyUnicode_Check() has been replaced.

Your example "__slots__ = {'some': 'mapping'} is somewhat strange. It works, but only because iterating dicts iterates the keys, and the key is a string. As far as I know, the value is ignored and useless, so I hope no one does this. Perhaps your only point was to test a non-sequence iterable of strings.

A patch should include a patch to the appropriate Lib/test/testxxx.py file.