I was recently thinking about how to add sizeof support to Dask for a particular library (Awkward Array). Currently, either Dask needs to be extended to support the library in question, or the library itself needs to be manually invoked to register the custom sizeof implementation.

I know that Dask can default to __sizeof__, but I'm not sure whether that is the best decision here. __sizeof__ should be the in-memory size of (just) the object, but in this particular case, an Awkward Array might not even own the data it refers to. I wouldn't expect __sizeof__ to report that memory. From the sys.getsizeof documentation,

Only the memory consumption directly attributed to the object is accounted for, not the memory consumption of objects it refers to.

I think that this would be a good candidate for entry_points. On startup, Dask can look for any registered entry-points that declare custom size-of functions, such that the user never needs to import the library explicitly on the worker, and the core of Dask can remain light-weight.

There are some performance concerns with entry_points, but projects like entrypoints claim to ameliorate the issue.