Neil Schemenauer <nas-pyt...@arctrix.com> added the comment:
Since C99 is now allowed, perhaps we should suggest that declarations go after
Py_TRASHCAN_BEGIN, e.g.
mytype_dealloc(mytype *p)
{
Py_TRASHCAN_BEGIN(p, mytype_dealloc)
... declarations go here ...
... The body of the deallocator goes here, including all calls ...
... to Py_DECREF on contained objects. ...
Py_TRASHCAN_END // there should be no code after this
}
The only dealloc method that doesn't fit this pattern is subtype_dealloc() and
that's because the object might not be a GC object.
Given the pattern, it occurs to me that that _Py_Dealloc() could do the
trashcan begin/end work. However, the authors of the dealloc methods would
have to realize the special rules of the trashcan (e.g. no returns from the
dealloc method body). Also, there would be some overhead added to
_Py_Dealloc() to check if the trashcan is supported. E.g. checking a type flag.
Another idea would be to add a new slot for the method, e.g. tp_dealloc_trash.
Then, _Py_Dealloc() could check if it exists and if so do the trashcan
begin/end dance around it. That would still add some overhead to _Py_Dealloc()
so I think the current macros are the best approach.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue44881>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
