[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 10/38] qapi/common.py: delint with pylint
From: |
Cleber Rosa |
Subject: |
Re: [PATCH v2 10/38] qapi/common.py: delint with pylint |
Date: |
Thu, 24 Sep 2020 15:30:51 -0400 |
On Wed, Sep 23, 2020 at 01:37:06PM -0400, John Snow wrote:
> 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
>
>
Not a too strong opinion about this to block it. So if I hadn't
already:
Reviewed-by: Cleber Rosa <crosa@redhat.com>
signature.asc
Description: PGP signature