[yt-dev] How to deal with old "Base" names for yt data objects?

[Nathan Goldbaum]

Hi all,

Recently I opened a PR (
https://bitbucket.org/yt_analysis/yt/pull-requests/1784) to improve the
time to create instances of yt Dataset objects.

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.

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

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

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.

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?

Thanks for your help and advice,

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20151011/7c5a4255/attachment.htm>