[Python-ideas] Do we need non-heap types any more? (Was: Implicit submodule imports)

[Nathaniel Smith]

On Sat, Sep 27, 2014 at 12:43 AM, Andrew Barnert
<abarnert at yahoo.com.dmarc.invalid> wrote:
> On Sep 26, 2014, at 14:43, Greg Ewing <greg.ewing at canterbury.ac.nz> 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