From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6F4B43F3A; Tue, 30 Apr 2024 12:49:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 79EF34025C; Tue, 30 Apr 2024 12:49:55 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id A40EB400EF for ; Tue, 30 Apr 2024 12:49:53 +0200 (CEST) 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 8F94D2F4; Tue, 30 Apr 2024 03:50:19 -0700 (PDT) Received: from [10.57.65.175] (unknown [10.57.65.175]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 739AB3F73F; Tue, 30 Apr 2024 03:49:52 -0700 (PDT) Message-ID: Date: Tue, 30 Apr 2024 11:49:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/5] dts: add parsing utility module Content-Language: en-GB To: Jeremy Spewock Cc: dev@dpdk.org, =?UTF-8?Q?Juraj_Linke=C5=A1?= , Paul Szczepanek References: <20240412111136.3470304-1-luca.vizzarro@arm.com> <20240412111136.3470304-4-luca.vizzarro@arm.com> From: Luca Vizzarro In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 29/04/2024 17:15, Jeremy Spewock wrote: > It would be helpful if this top level docstring explained more of how > to use the text parser and some examples of using a small dataclass > that chains some of these methods together. At first glance it wasn't > clear to me why things were done the way they were or what these > methods really provided, but looking at how you use it in the testpmd > shell made more sense. Ack. > This is declared but I don't see where it is used. There aren't many > typehints in this file, since these types can essentially be anything, > maybe using this could make some things slightly more clear (like, for > example, in eq v1 and v2 are the same type) but in most cases it's > implied so I'm not sure how beneficial this would be regardless. A remnant of previous code! Well spotted. > Is it simpler to default this to base 10? I assume that's what it'll > be most of the time so we might as well allow users to skip this > parameter. Base 0 just assumes the base of the number from the number prefix[1]. So if it's 0xAF it's base 16, 0o755 it's base 8 and so on. Of course base 10 is assumed with no prefix. I can certainly leave it as 10 as default, but is there a benefit to our purpose? > If we just skip instead of raising an exception here, would this solve > the issues caused by the first and last line in the testpmd output? > The check to see if the first line is an invalid port would obviously > still not work, but would it solve the problem of the trailing prompt? This exception is only raised when a field does not have a default value and there is no value to be assigned. Of course an exception is raised when attempting to construct and omitting a mandatory field, but this one is more meaningful as it provides context on what's wrong. It is not related to neither trailing/leading strings. These don't affect the functionality of the class. But rather the actual parsing done by the "user". [1] https://docs.python.org/3.10/library/functions.html#int