Remove unused _ancestry class variable

[t-b]

This is not written to NWB anymore.

[codecov]

Codecov Report

Merging #707 into dev will decrease coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #707      +/-   ##
==========================================
- Coverage   74.52%   74.42%   -0.11%     
==========================================
  Files          59       59              
  Lines        6849     6830      -19     
  Branches     1415     1415              
==========================================
- Hits         5104     5083      -21     
- Misses       1354     1355       +1     
- Partials      391      392       +1

Impacted Files	Coverage Δ
src/pynwb/behavior.py	100% <ø> (ø)	⬆️
src/pynwb/image.py	100% <ø> (ø)	⬆️
src/pynwb/ophys.py	94.54% <ø> (-0.1%)	⬇️
src/pynwb/ecephys.py	97.27% <ø> (-0.05%)	⬇️
src/pynwb/misc.py	98.43% <ø> (-0.07%)	⬇️
src/pynwb/icephys.py	88.88% <ø> (-0.59%)	⬇️
src/pynwb/ogen.py	100% <ø> (ø)	⬆️
src/pynwb/form/utils.py	86.76% <0%> (-0.59%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bfb5c83...e382672. Read the comment docs.

[bendichter]

Wait I actually like this. Is there currently no way to know from the nwb file how a class was derived? Would analysis tools benefit from access to this variable? Eg knowing that an extension derived from TimeSeries? If so it would probably be easier to do this automatically.

[oruebel]

ancestry should certainly not be stored in the file. That is the role of the schema and having the ancestry separately in the file is problematic.

[bendichter]

I guess the cached schema would accomplish this

[bendichter]

I don't really understand what's "problematic" about this though

[t-b]

From the cached spec in the file the ancestry can always be recovered.

[ajtritt]

@bendichter If you want ancestry, we could have the register_class decorator add it as a class attribute (this is how the neurodata_type class attribute gets added). Hardcoding it as a comma delimited string is problematic for long term maintenance and consistency. It’s just a field that would need to be kept in sync with the schema

[bendichter]

@ajtritt thanks for the explanation. @oruebel also pointed me to the discussion in the change logs. Let's remove this inactive code. Instead, how would you all feel about implementing a function that is analogous to isinstance but for neurodata_types instead of python classes using the schema?

[ajtritt]

looks good to me. Thanks @t-b

[ajtritt]

Instead, how would you all feel about implementing a function that is analogous to isinstance but for neurodata_types instead of python classes using the schema?

@bendichter that seems reasonable. I prefer we address that under a new issue though

[t-b]

@ajtritt @bendichter "Merge pull request" <-- Click here