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

[Matthew Turk]

Hi Nathan,

I would *guess* that extremely few people are using base objects directly.

One possibility would be to use the same thing we did for
GadgetStaticOutput and the like, and add deprecation notes for *those*
objects with the *Base naming convention, just inside each respective
.py file.  Since they're not imported even in yt.data_objects.api,
we're probably safe even if we didn't do this, but we can deprecate
and remove in a future 3.X release.  We should be okay.

-Matt

On Sun, Oct 11, 2015 at 11:20 AM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> 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
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>