qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 10/38] qapi/common.py: delint with pylint


From: John Snow
Subject: Re: [PATCH v2 10/38] qapi/common.py: delint with pylint
Date: Wed, 23 Sep 2020 13:37:06 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 9/23/20 12:01 PM, Cleber Rosa wrote:
On Tue, Sep 22, 2020 at 05:00:33PM -0400, John Snow wrote:
At this point, that just means using a consistent strategy for constant names.
constants get UPPER_CASE and names not used externally get a leading underscore.

As a preference, while renaming constants to be UPPERCASE, move them to
the head of the file. Generally, it's nice to be able to audit the code
that runs on import in one central place.

Signed-off-by: John Snow <jsnow@redhat.com>
---
  scripts/qapi/common.py | 18 ++++++++----------
  scripts/qapi/schema.py | 14 +++++++-------
  2 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/scripts/qapi/common.py b/scripts/qapi/common.py
index e0c5871b10..bddfb5a9e5 100644
--- a/scripts/qapi/common.py
+++ b/scripts/qapi/common.py
@@ -14,6 +14,11 @@
  import re
+EATSPACE = '\033EATSPACE.'
+POINTER_SUFFIX = ' *' + EATSPACE
+_C_NAME_TRANS = str.maketrans('.-', '__')

IMO _C_NAME_TRANS is solely the concern of the c_name() function, and
should not be a global.  If you're concerned with speed (which I don't
think you should) you could still do:


It's true, but that's why it's marked internal here with the leading underscore -- it will not be exported. It was also *already* defined at the module level, I didn't hoist it.

I think what is written here is already the simplest thing that works.

    def c_name(name, protect=True,
               name_translation=str.maketrans('.-', '__')):
       ...
       name = name.translate(name_translation)

Keeping in mind that you're adding a mutable type to a function
argument *on purpose*.  I'd really favor having that statement within
the only function that uses it, though.


That complicates the signature, so I think we shouldn't.

--js




reply via email to

[Prev in Thread] Current Thread [Next in Thread]