Particle.pdgid should return int

Context: I use Numba a lot, so it would be great if particle would work with Numba directly, but I guess that this is probably a more elaborate project. In the meantime as a workaround, I extract information from particle and store that in Python lists and dicts, which I then pass to the numba-compiled functions.

The attribute Particle.pdgid is of type particle.pdgid.pdgid.PDGID instead of int, which leads to unexpected issues. I argue it would be better to return a plain int. The type particle.pdgid.pdgid.PDGID emulates a plain int, so you won’t notice the difference much in pure Python, but it is a different type nonetheless and Numba does not understand this type. If I prepare a list or dict of PDG IDs to pass to Numba, I need to call int(Particle.pdgid) explicitly, which is doable but irritating.

I argue that there is no benefit of Particle.pdgid being particle.pdgid.pdgid.PDGID here, because the extra information that can be queried from particle.pdgid.pdgid.PDGID is can already be queried from Particle.

[henryiii]

PS: int(p) produces an int, and PDGID(p) produces a PDGID. p.pdgid is just a shortcut for PDGID(p).

Second reminder: you can also make Particles that do not have a valid PDGID by specifying all the properties. int(p) may fail.

[henryiii]

Perhaps you heard somewhere that composition is better than inheritance

This was partially a historical result, rather than a conscious design. @eduardo-rodrigues mostly wrote PDGID, and I mostly wrote Particle. PDGID did not exist when Particle was designed, so it would be quite odd for Particle to inherit from it.

A 1.0 redesign could possibly include larger changes, and possibly include moving the particle search functionality out of Particle and into a Particles/ParticleTable class (have not thought about it at this point, maybe @eduardo-rodrigues has). Another option would be to reduce the correspondence between PDGID’s and Particles, and instead treat pdgid as one of many possible representations, removing __int__().

PS: I really don’t like APIs like “make a singleton-like class then use it” for a library supporting beginners, but we might be able to provide beginner friendly options and a “default” particle table.

The defense of the current design would be that the intent of int(Particle(...)) is clear - you are asking for a int representation of the current particle, and that by far most likely to be a PDG ID int (see option two, though, which might remove this). But a particle is not an int; it just has a explicit conversion to an int. abs(Particle(...)) fails (or should return a Particle, possibly?). Particle(...) + 1 has no meaning, since not all particles exist. PDGID() + 1 does, since it’s just an int representing the ID of a particle. (PDGID(...) + 1).has_charm is a perfectly valid question. PDGID is valid for all possible ints, while Particle is a lookup-based object; the really do not have anything in common. Particle is not supposed to duck type as an int, while PDGID does (since it is an int). While PDGID is an int, but also has further information beyond an int.

Again, the real problem is that Numba is picky, and doesn’t treat subclasses of ints as ints like normal Python does. But we could probably easily teach it otherwise (maybe even teaching it a few details about PDGIDs, in fact) if there’s a strong enough desire for it.

PS: @eduardo-rodrigues , if you are interested in enabling all PDGID’s methods on particle, but without turning Particles also into ints and causing Particle() + 1 to “work” but make an invalid particle, we can explore this; I have a simple idea for how this could be done.