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

[Andrew Barnert]

On Sep 26, 2014, at 17:03, Nathaniel Smith <njs at pobox.com> wrote:

> 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.

Yes, I wasn't sure whether Greg was suggesting to get rid of actual non-heap-allocated types, or just making static types fit HEAPTYPE. The former would be a lot more work, but it would also allow simplifying a lot of additional things, so they both seem like reasonable things to suggest (whether or not they're both reasonable things to actually do),

> 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),

Well, there's obviously a non-zero performance cost to doing all this stuff with all types. Of course there's also a non-zero cost to checking the heap-type-ness of all types. And both costs may be so minimal they're hard to even measure.

> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/