From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 7FE1345C0A;
	Tue, 29 Oct 2024 13:41:43 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 6B5904014F;
	Tue, 29 Oct 2024 13:41:43 +0100 (CET)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by mails.dpdk.org (Postfix) with ESMTP id 33BFB40144
 for <dev@dpdk.org>; Tue, 29 Oct 2024 13:41:42 +0100 (CET)
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2BC8813D5;
 Tue, 29 Oct 2024 05:42:11 -0700 (PDT)
Received: from [10.57.58.134] (unknown [10.57.58.134])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 975493F73B;
 Tue, 29 Oct 2024 05:41:40 -0700 (PDT)
Message-ID: <ffa6c365-fa61-4d4d-a315-5cc4577e6793@arm.com>
Date: Tue, 29 Oct 2024 12:41:39 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 3/5] dts: use Pydantic in the configuration
Content-Language: en-GB
To: Nicholas Pratte <npratte@iol.unh.edu>
Cc: dev@dpdk.org, Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
 =?UTF-8?Q?Juraj_Linke=C5=A1?= <juraj.linkes@pantheon.tech>,
 Paul Szczepanek <paul.szczepanek@arm.com>
References: <20240822163941.1390326-1-luca.vizzarro@arm.com>
 <20240822163941.1390326-4-luca.vizzarro@arm.com>
 <CAKXZ7egaKAh=5L5WpHO1aYvFbtWZcowu3nihy9Mgmbp+0oxs7Q@mail.gmail.com>
From: Luca Vizzarro <Luca.Vizzarro@arm.com>
In-Reply-To: <CAKXZ7egaKAh=5L5WpHO1aYvFbtWZcowu3nihy9Mgmbp+0oxs7Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

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.