<div dir="ltr">Hi all,<div><br></div><div>Recently I opened a PR (<a href="https://bitbucket.org/yt_analysis/yt/pull-requests/1784">https://bitbucket.org/yt_analysis/yt/pull-requests/1784</a>) to improve the time to create instances of yt Dataset objects.</div><div><br></div><div>I found that our use of the python builtin 'type' function to handle associating data object factories (e.g. the ds.all_data() function) with Dataset instances was a large contribution, with overhead from sympy dominating the load time for a single dataset. Since sympy uses caching, in the long term the call to "type" dominates the runtime.</div><div><br></div><div>'type', the way we were using it, is equivalent to having a class definition, so a long time ago it was set up such that all of the data object definitions were given names like YTSliceBase, but then you would get back an instance of YTSlice since the 'type' function was dynamically defining a subclass that ensured the dataset instance is passed to the data object initializer.</div><div><br></div><div>I found that we can do this a lot faster using functools.partial, at the cost of all data objects having incorrect class names (i.e. ds.all_data() becomes an instance of YTRegionBase instead of YTRegion).</div><div><br></div><div>I think the correct thing to do is to have all yt data objects drop the "Base" part of their name and just forget about this type indirection business. On the other hand, the data object API is about as core to yt as anything else is, and I worry that doing this might break user scripts.</div><div><br></div><div>Does anything think anyone is actually importing YTRegionBase or other yt data object and using it in their code somehow? Our documented entry point is via the data object creation member functions, although we do mention the names of these classes in the API docs. Should I define a set of aliases for compatibility so people's scripts don't break? Is this whole approach too risky?</div><div><br></div><div>Thanks for your help and advice,</div><div><br></div><div>-Nathan</div></div>