diff options
author | Tim Peters <tim.peters@gmail.com> | 2001-10-06 21:27:34 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2001-10-06 21:27:34 (GMT) |
commit | 6d483d3477c37d7dfe3113ef6fd02ba02c78fde6 (patch) | |
tree | a411a61b3fa22b4ddc912b5c4b4dc3196a377355 /Include/sysmodule.h | |
parent | 406fe3b1c029e2526f4aeab070cc93177512f164 (diff) | |
download | cpython-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