From: Markus Armbruster <armbru@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH v3 14/20] qapi/schema: Don't initialize "members" with `None`
Date: Wed, 13 Mar 2024 07:57:10 +0100 [thread overview]
Message-ID: <87cyryipq1.fsf@pond.sub.org> (raw)
In-Reply-To: <CAFn=p-Yb935TK-FmKtun+wWPjZjMYPOAivHOLUQK0hZr64Gh1w@mail.gmail.com> (John Snow's message of "Tue, 12 Mar 2024 17:10:53 -0400")
John Snow <jsnow@redhat.com> writes:
> On Tue, Feb 20, 2024 at 10:03 AM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> John Snow <jsnow@redhat.com> writes:
>>
>> > Declare, but don't initialize the "members" field with type
>> > List[QAPISchemaObjectTypeMember].
>> >
>> > This simplifies the typing from what would otherwise be
>> > Optional[List[T]] to merely List[T]. This removes the need to add
>> > assertions to several callsites that this value is not None - which it
>> > never will be after the delayed initialization in check() anyway.
>> >
>> > The type declaration without initialization trick will cause accidental
>> > uses of this field prior to full initialization to raise an
>> > AttributeError.
>> >
>> > (Note that it is valid to have an empty members list, see the internal
>> > q_empty object as an example. For this reason, we cannot use the empty
>> > list as a replacement test for full initialization and instead rely on
>> > the _checked/_checking fields.)
>> >
>> > Signed-off-by: John Snow <jsnow@redhat.com>
>> > ---
>> > scripts/qapi/schema.py | 13 +++++++------
>> > 1 file changed, 7 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
>> > index a459016e148..947e7efb1a8 100644
>> > --- a/scripts/qapi/schema.py
>> > +++ b/scripts/qapi/schema.py
>> > @@ -20,7 +20,7 @@
>> > from collections import OrderedDict
>> > import os
>> > import re
>> > -from typing import List, Optional
>> > +from typing import List, Optional, cast
>> >
>> > from .common import (
>> > POINTER_SUFFIX,
>> > @@ -457,7 +457,7 @@ def __init__(self, name, info, doc, ifcond, features,
>> > self.base = None
>> > self.local_members = local_members
>> > self.variants = variants
>> > - self.members = None
>> > + self.members: List[QAPISchemaObjectTypeMember]
>> > self._checking = False
>> >
>> > def check(self, schema):
>> > @@ -474,7 +474,7 @@ def check(self, schema):
>> >
>> > self._checking = True
>> > super().check(schema)
>> > - assert self._checked and self.members is None
>> > + assert self._checked
>>
>> This asserts state is "2. Being checked:.
>>
>> The faithful update would be
>>
>> assert self._checked and self._checking
>>
>> Or with my alternative patch
>>
>> assert self._checked and not self._check_complete
>> >
>> > seen = OrderedDict()
>> > if self._base_name:
>> > @@ -491,7 +491,10 @@ def check(self, schema):
>> > for m in self.local_members:
>> > m.check(schema)
>> > m.check_clash(self.info, seen)
>> > - members = seen.values()
>> > +
>> > + # check_clash is abstract, but local_members is asserted to be
>> > + # List[QAPISchemaObjectTypeMember]. Cast to the narrower type.
>>
>> What do you mean by "check_clash is abstract"?
>>
>> > + members = cast(List[QAPISchemaObjectTypeMember], list(seen.values()))
>>
>> Do we actually need this *now*, or only later when we have more type
>> hints?
>>
>> >
>> > if self.variants:
>> > self.variants.check(schema, seen)
>> > @@ -524,11 +527,9 @@ def is_implicit(self):
>> > return self.name.startswith('q_')
>> >
>> > def is_empty(self):
>> > - assert self.members is not None
>>
>> This asserts state is "3. Checked".
>>
>> The faithful update would be
>>
>> assert self._checked and not self._checking
>>
>> Or with my alternative patch
>>
>> assert self._check_complete
>>
>> > return not self.members and not self.variants
>> >
>> > def has_conditional_members(self):
>> > - assert self.members is not None
>>
>> Likewise.
>
> Do we even need these assertions, though? If members isn't set, it's
> gonna crash anyway. I don't think you actually need them at all. I
> think it's fine to leave these changes in this patch and to remove the
> assertion as it no longer really guards anything.
When I wrote my review comment, my mind was running on "mechanical
transformation" rails: "the faithful update would be". The "in state 3"
predicate is .members is not None before the patch, and ._check_complete
afterwards.
You're right, the assertion no longer guards. It can at best aid
understanding the code. Feel free to drop it.
Would it make sense to explain the transformation of the "in state N"
predicates briefly in the commit message?
>> > return any(m.ifcond.is_present() for m in self.members)
>> >
>> > def c_name(self):
>>
>> This patch does two things:
>>
>> 1. Replace test of self.members (enabled by the previous patch)
>>
>> 2. Drop initialization of self.members and simplify the typing
>>
>> Observation, not demand. Wouldn't *mind* a split, though :)
>>
>
> I think maybe one of the assertions can be replaced in the previous
> patch, but I think everything else does really belong in this patch.
My observation is that this patch could be split in two, not that parts
of it belong to the previous patch.
next prev parent reply other threads:[~2024-03-13 6:57 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 22:42 [PATCH v3 00/20] qapi: statically type schema.py John Snow
2024-02-01 22:42 ` [PATCH v3 01/20] qapi: sort pylint suppressions John Snow
2024-02-01 22:42 ` [PATCH v3 02/20] qapi/schema: add " John Snow
2024-02-01 22:42 ` [PATCH v3 03/20] qapi: create QAPISchemaDefinition John Snow
2024-02-01 22:42 ` [PATCH v3 04/20] qapi/schema: declare type for QAPISchemaObjectTypeMember.type John Snow
2024-02-01 22:42 ` [PATCH v3 05/20] qapi/schema: declare type for QAPISchemaArrayType.element_type John Snow
2024-02-01 22:42 ` [PATCH v3 06/20] qapi/schema: make c_type() and json_type() abstract methods John Snow
2024-02-01 22:42 ` [PATCH v3 07/20] qapi/schema: adjust type narrowing for mypy's benefit John Snow
2024-02-01 22:42 ` [PATCH v3 08/20] qapi/schema: add type narrowing to lookup_type() John Snow
2024-02-20 10:39 ` Markus Armbruster
2024-03-11 18:14 ` John Snow
2024-03-11 18:26 ` John Snow
2024-03-12 7:32 ` Markus Armbruster
2024-02-01 22:42 ` [PATCH v3 09/20] qapi/schema: assert resolve_type has 'info' and 'what' args on error John Snow
2024-02-20 10:48 ` Markus Armbruster
2024-03-11 18:37 ` John Snow
2024-03-12 7:33 ` Markus Armbruster
2024-02-01 22:42 ` [PATCH v3 10/20] qapi: use schema.resolve_type instead of schema.lookup_type John Snow
2024-02-20 15:17 ` Markus Armbruster
2024-03-11 18:44 ` John Snow
2024-02-01 22:42 ` [PATCH v3 11/20] qapi/schema: fix QAPISchemaArrayType.check's call to resolve_type John Snow
2024-02-01 22:42 ` [PATCH v3 12/20] qapi/schema: assert info is present when necessary John Snow
2024-02-01 22:42 ` [PATCH v3 13/20] qapi/schema: split "checked" field into "checking" and "checked" John Snow
2024-02-20 13:29 ` Markus Armbruster
2024-03-12 21:04 ` John Snow
2024-02-01 22:42 ` [PATCH v3 14/20] qapi/schema: Don't initialize "members" with `None` John Snow
2024-02-20 15:03 ` Markus Armbruster
2024-03-12 21:10 ` John Snow
2024-03-13 6:57 ` Markus Armbruster [this message]
2024-03-13 16:57 ` John Snow
2024-03-12 21:16 ` John Snow
2024-02-01 22:42 ` [PATCH v3 15/20] qapi/schema: fix typing for QAPISchemaVariants.tag_member John Snow
2024-02-20 15:20 ` Markus Armbruster
2024-02-01 22:42 ` [PATCH v3 16/20] qapi/schema: assert inner type of QAPISchemaVariants in check_clash() John Snow
2024-02-01 22:42 ` [PATCH v3 17/20] qapi/parser: demote QAPIExpression to Dict[str, Any] John Snow
2024-02-01 22:42 ` [PATCH v3 18/20] qapi/schema: add type hints John Snow
2024-02-01 22:42 ` [PATCH v3 19/20] qapi/schema: turn on mypy strictness John Snow
2024-02-01 22:42 ` [PATCH v3 20/20] qapi/schema: remove unnecessary asserts John Snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyryipq1.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=jsnow@redhat.com \
--cc=michael.roth@amd.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).