Closed BestClaws closed 1 year ago
AscensionMaterial
would be end-user friendly in my opinion, and easy to access. The former is fine too, but would require more line of codes, for consumer | end-user to get the required data.
will go with AscensionMaterail
then. ill save myself with AscensionMaterials
thought since its redundant with list. Also this decision should reflect on other data models as well
This is a draft pull requests. idea is to discuss , make additional changes before merging.
I'm kinda iffy about type definition for this property in light cone model (see hsr_client/datamodels/lightcone.py in PR) the type feels too long for me, how do you feel about this.
alternative is to create more sub types like
where,
AscensionMaterials
could be an iterator so we can doand
ascension_mat
could be of typeAscensionMaterial
so we can do
but this introduces 2 more types , unncessarily.