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

[John ZuHone]

Agree here with Matt. *Base seems superfluous at this point. 

Good catch!

> On Oct 11, 2015, at 2:57 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> 
> 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
>> 
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org