Subclassing the Particle class from PlasmaPy

[wtbarnes]

Question: Should the Ion class subclass the Particle class from PlasmaPy?

The atomic subpackage in PlasmaPy provides an object for representing particles via the Particle class. Particle provides a convenient API to lots of metadata, e.g. mass, atomic number, symbol, etc. This would mean fiasco wouldn't have to re-implement all of this functionality.

fiasco already relies on PlasmaPy for getting the atomic number, symbol, and name.

Would there be any major conflicts with the existing Ion class and Particle? What would be the major benefits? Is the Particle API stable enough to rely that heavily on it?

[wtbarnes]

@namurphy Do you have any thoughts on this? This would mean that fiasco would depend on Plasmapy which I think is fairly logical.

[namurphy]

Is the Particle API stable enough to rely that heavily on it?

I think the Particle class is one of the least unstable parts of PlasmaPy, though there may be some changes since every part of PlasmaPy is unstable right now. Attributes like atomic_number, mass, element, integer_charge, roman_symbol, etc. that are named intuitively (or perhaps even named optimally) are likely to stay the same. There's a higher chance that things like is_category will change, or things that might not be named optimally. If you do this, it'd be good to test against both version 0.1.1 and the development version of PlasmaPy. (I had trouble the last time I tried to test against astropy-dev but hopefully someone else can provide advice on how to do this, if you're not doing it already!)

One possible downside is that there are a bunch of additional methods and attributes to Particle that may be unnecessary to Ion, in which case the attributes that are useful may be a littler harder for users to find. I think that's a fairly small problem though.

Overall, this sounds like a very reasonable thing to do to me, especially if it will make your life easier.

[wtbarnes]

OK this is good to hear. I'd like to have better integration with PlasmaPy as I think this will reduce duplication of effort between fiasco and plasmapy.atomic. Stability is not too big of an issue as fiasco is very unstable too, much more so than PlasmaPy! I'm happy to make changes to the API if it means better compatibility with PlasmaPy.