In Raymond said that a dict structure can be switched to PyVarObject. Victor guessed that it makes sense to switch a set structure too. Proposed patch implements this. The layout of a dict structure is not changed. The number of used and filled entries in a set structure are swapped, therefore extensions that use PySet_GET_SIZE or access fields of PySetObject directly (both are not in a stable API) should be recompiled. I don't see a benefit from this patch except some unification.
Copy/paste of my : > dict doesn't end with array. Right, but... Recently I looked at dict internals. As a newcomer, I have to confess that it's currently really hard to understand the purpose of each dict field: they are many "sizes": size of the hash table, number of usable entries, number of used entries, number of items in the dictionary, etc. I like the idea of using the standard ob_size field (PyVarObject) to make it more explicitl that this field is the expected result of len(obj). Technically, I don't know any function inside Python core which rely on the fact that object data is at the end of the main memory block. Other builtin Python types: * tuple: PyVarObject * list: PyVarObject * bytes: PyVarObject * bytearray: PyVarObject * memoryview: PyVarObject * set: "used" field * str: "length" field The str type is super optimized for memory footprint, there are technical reasons for not used PyVarObject here, like backward compatibility. It may make sense to modify PySetObject to use PyVarObject as well, but that's a different topic :-)
> Since I don't see a benefit from this change I leave both patches > to you Raymond. After more reflection, I also don't see any point of doing this. While there is a minor whiff of consistency when using Py_SIZE(), it makes the assignment look weird and inconsistent between filled and used. I now favor local consistency and clarity (with in setobject.c) over trying to make it look exactly like some other modules.
