On 30/09/2024 18:56, Nicholas Pratte wrote:
+the YAML test run configuration file and validates it against the
:class:`Configuration` Pydantic
+dataclass model. The Pydantic model is also available as
Out of curiosity, what is the reason for maintaining use of
dataclasses here as opposed to creating BaseModel subclasses for the
Pydantic library? I suppose both implementations would lead to the
same result, but is it mostly for the sake of familiarity and
consistency that we're still using dataclasses here?
The original idea was as you said, familiarity and consistency, but it
actually brings extra headaches and it's unnecessary. I've used
BaseModel for everything in the newer versions.
@unique
-class TrafficGeneratorType(StrEnum):
+class TrafficGeneratorType(str, Enum):
"""The supported traffic generators."""
#:
- SCAPY = auto()
+ SCAPY = "SCAPY"
Going off of Juraj's comments, would you be able to provide an deeper
explanation as how this new parameterization of str and enum works
with respect to the Pydantic field discriminators?
This is something I am not able to explain unfortunately. For some
reason – I am not 100% sure how Pydantic works in this case – the
original implementation was incompatible with the discriminator.
Retaining the original setup made Pydantic use values of:
"<TrafficGeneratorType.SCAPY: SCAPY>"
instead of plain "SCAPY", for some reason. So it's an incompatibility issue.
