I've a database query that returns a dataset, which is naturally well represented by a dict. However I also need to add in metadata and other objects about it for other reasons. I also then need to be able to pull out the real data from the object on demand without the augmented items getting in the mix.
Originally I was adding in other bits and in a get() method, explicitly removing them, which isn't scalable, but I wanted to just extend a dict originally, and at the superficial level being able to call object.attribute is quite hard to resist compared to object.
Another route is to have an internal inside the object I could just grab with object.the_data and leave __dict__ for the meta side of things. However then I've a cumbersome route to accessing this dict, and at the superficial level being able to call object.attribute is quite hard to resist compared to object.the_data['attribute'].
In line with this though, I was then looking at if it's just absurd to automatically create custom getters (probably not setters) for every key in the dict that the object is created with. If it's not, then an example of this when you do NOT know all the attributes you are getting would be awesome. I See some interesting stuff here: Is it possible to generate getters and setters functions based on some sort of attribute automatically?, but this doesn't (appear to) leave me able to call object.attribute, it would still need to be attribute() or such.
Another middle ground I can think of is to make any passed attribute into object._attribute so it's generically easy to know which items are the "real" data for my other helper methods. However by that point, you'd just use a separate dictionary I guess? Whilst I'm thinking all this though, should it actually be the meta side that is pushed back to underscores? Maybe i've been thinking about this backwards?
What's a reasonable approach to take in designing this new multipurpose object class where I can ideally reference object.attribute in ignorance to how it's working?