On Sat, Sep 27, 2014 at 12:43 AM, Andrew Barnert
On Sep 26, 2014, at 14:43, Greg Ewing
wrote: Antoine Pitrou wrote:
The tp_dealloc for a heap type is not the same as the non-heap base type's tp_dealloc. Also, look at compatible_for_assignment(): it calls same_slots_added() which assumes both args are heap types.
It looks like the easiest way to address this particular use case would be to make the module type a heap type.
In the long term, how about turning *all* types into heap types? We're already having to call PyType_Ready on all the static type objects, so allocating them from the heap shouldn't incur much extra overhead.
What about extension modules? Deprecate static types? Automatically copy them to heap types? Use some horrible macro tricks in Python.h or a custom preprocessor in distutils?
I think the name "heap types" is misleading. The actual distinction being made isn't really about where the type object is allocated. Static type objects are still subject to the refcounting machinery in most cases (try sys.getrefcount(int)), but this is fine because the refcount never reaches zero. AFAICT from skimming the source a bit, what happened back in the 2.2 days is that the devs went around fixing all the random places where the assumption that all type objects were immortal had snuck in, and they hid all this fixes behind a generic switch called "heap types". It's all stuff like "we'll carefully only do standard refcounting if HEAPTYPE is set" (even though refcounting could be applied to all types without causing any problems), or "we will disable the GC machinery when walking non-heap types" (even though again, who cares), or "heap types all use the same tp_dealloc function". I'm sure some of this stuff we're stuck with due to backcompat with C extension modules that make funny assumptions, but presumably a lot of it could be cleaned up -- I think that's what Greg means. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org