Terry J. Reedy <[email protected]> added the comment:
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.
----------
nosy: +terry.reedy
stage: -> needs patch
versions: -Python 3.2
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue13290>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
