Using Pydantic for Configurations #159
Replies: 1 comment 11 replies
-
|
With these kinds of types, the type model is part of the art. One way of thinking about it is hierarchically: you have a certain number of basic types that only consist of builtins/etc., and then higher-order types that integrate them. So then in that framing the problem of needing to subset some fields of a type is a problem of not having composed it of fine enough components, aggregating too soon, etc. For example your 'top level' params class could resolve that in at least two ways: one is that you make that group of params as arduino params, and then include it in the top-level class. Another is that both the top-level params object and the arduino params object share some "lower level" parameter types. There's a distinction between three things here, the first two of which are familiar from regular python:
so the first mode of nesting types is strictly preferable, as being able to compose individual attributes into recognizable groups is the whole idea. In the last example, it looks like you're mixing up the notion of type and default, and mixing up the "direction" of inheritance. It seems like you want to make a subset of the I think it might be useful to check out the docs for the typing module as well, as there are plenty of places where it looks like you'd probably want to declare, for example, a list of integers like |
Beta Was this translation helpful? Give feedback.
-
|
definitely discourage using functions to update stuff in the model instances -- it sort of defeats the purpose. the whole point of having these explicit data models is that you can verifiably rely on certain values existing and having a certain type. if you need to call a bunch of functions on a model after you make it then you lose that! if you have some attributes/arrays/values that are derived from the parameters, use properties or instance methods. Class methods are for when the class as a whole needs to be able to do something. a common pattern is to do something like this class MyClass:
@classmethod
def from_string(cls, input:str) -> MyClass:
# do something to create the class from a string
return cls(whatever) |
Beta Was this translation helpful? Give feedback.
-
|
also, definitely do type hinting. another one of those "that's the whole point" kind of things. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much for these tips! That makes sense that you'd want to be doing it all through the classes since it is literally the point of them lol. Is there a way to provide attributes from higher up in the model? For example, the ITI array I need to make needs to have the number of elements inside equal to the total number of trials. I'm not sure how to feed in the |
Beta Was this translation helpful? Give feedback.
-
|
can i see a minimal example, in pseudocode if needed, of the model you're thinking of and what you want it to do? brain fried and can't quite parse this/the above models. when you can't figure out if something is working as you expect, i like to make toy examples. so to see how inheritance is different than being a class attribute something like class Child:
b = 'b'
class Parent:
a = 'a'
child = Child()
# does my child have access to the parent value?
>>> assert hasattr(Child(), 'a')vs. class Parent:
a = 'a'
class Child(Parent):
b = 'b'
# does my child have access to the parent value?
assert hasattr(Child(), 'a') |
Beta Was this translation helpful? Give feedback.
-
|
I changed where the property goes and it seems to work! I had the inheritance backwards again. The organization of it basically is (pseudocode for model then real property): But then I have all these other properties at the top level of the structure, meaning I will have a bunch more properties tags beneath my top level class. Is it bad to have them at that level design wise? I also feel like having to do EDIT: For better or worse, I know can generate all my arrays using classes and I access them all as properties! Woohoo! I still have to do |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello everyone!
I'm taking a break from trying to understand synaptic physiology by messing around with Pydantic. It'd be great to have class objects I manipulate instead of indexing different dictionaries like I currently do. Here's an example of a current configuration file. I think it'd be ideal to use Autopilot for these things and extend it so it can interface with Bruker microscopes, but in the meantime I'm just trying to learn pydantic and classes more generally. I figured I'd post here to see what people thought.
I'm wondering if I should change how my configuration files are formatted. Maybe something like this:
Or maybe something like this:
Pydantic can make some nice subclasses for you automatically, and the first reformat looks like this on the python side:
If I do it the second way, it looks like this:
I think both are better ways of accessing data in the program, but the thing I'm unsure about is how to make new classes that are composed of just some pieces of these fields. For example, at the moment with the Arduino, these fields are required to set the board up to do the correct stimuli:
This takes some pieces of one class while taking different pieces of another. I feel like this means I'm just doing all of this badly. Are both of these organizations garbage? Does it make sense to make a new class that's just composed of different pieces of other classes?
Curious what you all think...
Beta Was this translation helpful? Give feedback.
All reactions