Enable __slots__ for meta-types

[tismer]

BPO	696184
Files	typeobject.diff: diff file for typeobject.c and object.h, against today's CVS version.

^{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:

assignee = None
closed_at = <Date 2003-03-02.20:54:35.000>
created_at = <Date 2003-03-02.20:52:31.000>
labels = ['type-feature']
title = 'Enable __slots__ for meta-types'
updated_at = <Date 2003-03-02.20:54:35.000>
user = 'https://bugs.python.org/tismer'

bugs.python.org fields:

activity = <Date 2003-03-02.20:54:35.000>
actor = 'tismer'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['None']
creation = <Date 2003-03-02.20:52:31.000>
creator = 'tismer'
dependencies = []
files = ['8217']
hgrepos = []
issue_num = 696184
keywords = []
message_count = 1.0
messages = ['53791']
nosy_count = 1.0
nosy_names = ['tismer']
pr_nums = []
priority = 'low'
resolution = None
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue696184'
versions = []

[tismer]

The new type system allows non-empty __slots__ only
for fixed-size objects.

Meta-types are types which instances are also types.
types are variable-sized, because they take the slot
definitions for their instances, so the cannot have
extra members from their meta-type.

The proposed solution allows for two things:
a) meta-types can have slots
b) extensions get access to the whole type object and
can create extended types with private fields.

The changes providing this are quite simple:

• replace the internal hidden "etype" and turn it into
  an explicit PyHeapTypeObject in object.h
• instead of a fixed offset into the former etype, the
  slots
  calculation is based upon tp_basicsize.

To keep things easy, I added a macro which does this
calculation, and member access read now like so:

before:
type->tp_members = et->members;
after:
type->tp_members = PyHeapType_GET_MEMBERS(et);

This patch has been tested thoroughly in my own code since
Python 2.2, and I think it is ripe to get into the
distribution.
It has almost no impact on speed or complexity.