Currently QREF objects can come in different forms:
- Saved to a file
- Represented as a dictionary
- Instances of pydantic models (
SchemaV1)
This introduces some ambiguity, as when we say "QREF object", we could mean any of these.
It would be good to clarify the language here, below is a proposal for this:
- "QREF file" would refer to a JSON or YAML file adhering to QREF schema
- "QREF dictionary" would refer to a Python dictionary adhering to QREF schema
- "QREF object" would refer to an instance of QREF pydantic model
Keep in mind that in future QREF pydantic models might become generic (i.e. they would support not only strings as expressions, but also other types, e.g.: sympy expressions). In such case we could imagine having dictionaries containing non-native expression types. Such dictionary would be a valid input for creating a QREF object. However, we should not call it "QREF dictionary", as it is not JSON/YAML-serializable.
Once we agree on what the good naming is, we should update documentation (including docstrings!) accordingly.
CC: @dexter2206 @sammorley-short
Currently QREF objects can come in different forms:
SchemaV1)This introduces some ambiguity, as when we say "QREF object", we could mean any of these.
It would be good to clarify the language here, below is a proposal for this:
Keep in mind that in future QREF pydantic models might become generic (i.e. they would support not only strings as expressions, but also other types, e.g.: sympy expressions). In such case we could imagine having dictionaries containing non-native expression types. Such dictionary would be a valid input for creating a QREF object. However, we should not call it "QREF dictionary", as it is not JSON/YAML-serializable.
Once we agree on what the good naming is, we should update documentation (including docstrings!) accordingly.
CC: @dexter2206 @sammorley-short