summaryrefslogtreecommitdiffstats
path: root/Include/sysmodule.h
diff options
context:
space:
mode:
authorTim Peters <tim.peters@gmail.com>2001-10-06 21:27:34 (GMT)
committerTim Peters <tim.peters@gmail.com>2001-10-06 21:27:34 (GMT)
commit6d483d3477c37d7dfe3113ef6fd02ba02c78fde6 (patch)
treea411a61b3fa22b4ddc912b5c4b4dc3196a377355 /Include/sysmodule.h
parent406fe3b1c029e2526f4aeab070cc93177512f164 (diff)
downloadcpython-6d483d3477c37d7dfe3113ef6fd02ba02c78fde6.zip
cpython-6d483d3477c37d7dfe3113ef6fd02ba02c78fde6.tar.gz
cpython-6d483d3477c37d7dfe3113ef6fd02ba02c78fde6.tar.bz2
_PyObject_VAR_SIZE: always round up to a multiple-of-pointer-size value.
As Guido suggested, this makes the new subclassing code substantially simpler. But the mechanics of doing it w/ C macro semantics are a mess, and _PyObject_VAR_SIZE has a new calling sequence now. Question: The PyObject_NEW_VAR macro appears to be part of the public API. Regardless of what it expands to, the notion that it has to round up the memory it allocates is new, and extensions containing the old PyObject_NEW_VAR macro expansion (which was embedded in the PyObject_NEW_VAR expansion) won't do this rounding. But the rounding isn't actually *needed* except for new-style instances with dict pointers after a variable-length blob of embedded data. So my guess is that we do not need to bump the API version for this (as the rounding isn't needed for anything an extension can do unless it's recompiled anyway). What's your guess?
Diffstat (limited to 'Include/sysmodule.h')
0 files changed, 0 insertions, 0 deletions