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>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH 15/19] qapi/parser: demote QAPIExpression to Dict[str, Any]
Date: Thu, 23 Nov 2023 15:12:31 +0100 [thread overview]
Message-ID: <8734ww4kz4.fsf@pond.sub.org> (raw)
In-Reply-To: <20231116014350.653792-16-jsnow@redhat.com> (John Snow's message of "Wed, 15 Nov 2023 20:43:46 -0500")
John Snow <jsnow@redhat.com> writes:
> Dict[str, object] is a stricter type, but with the way that code is
> currently arranged, it is infeasible to enforce this strictness.
>
> In particular, although expr.py's entire raison d'être is normalization
> and type-checking of QAPI Expressions, that type information is not
> "remembered" in any meaningful way by mypy because each individual
> expression is not downcast to a specific expression type that holds all
> the details of each expression's unique form.
>
> As a result, all of the code in schema.py that deals with actually
> creating type-safe specialized structures has no guarantee (myopically)
> that the data it is being passed is correct.
>
> There are two ways to solve this:
>
> (1) Re-assert that the incoming data is in the shape we expect it to be, or
> (2) Disable type checking for this data.
>
> (1) is appealing to my sense of strictness, but I gotta concede that it
> is asinine to re-check the shape of a QAPIExpression in schema.py when
> expr.py has just completed that work at length. The duplication of code
> and the nightmare thought of needing to update both locations if and
> when we change the shape of these structures makes me extremely
> reluctant to go down this route.
>
> (2) allows us the chance to miss updating types in the case that types
> are updated in expr.py, but it *is* an awful lot simpler and,
> importantly, gets us closer to type checking schema.py *at
> all*. Something is better than nothing, I'd argue.
>
> So, do the simpler dumber thing and worry about future strictness
> improvements later.
Yes.
While Dict[str, object] is stricter than Dict[str, Any], both are miles
away from the actual, recursive type.
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> scripts/qapi/parser.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/qapi/parser.py b/scripts/qapi/parser.py
> index bf31018aef0..b7f08cf36f2 100644
> --- a/scripts/qapi/parser.py
> +++ b/scripts/qapi/parser.py
> @@ -19,6 +19,7 @@
> import re
> from typing import (
> TYPE_CHECKING,
> + Any,
> Dict,
> List,
> Mapping,
> @@ -43,7 +44,7 @@
> _ExprValue = Union[List[object], Dict[str, object], str, bool]
>
>
> -class QAPIExpression(Dict[str, object]):
> +class QAPIExpression(Dict[str, Any]):
> # pylint: disable=too-few-public-methods
> def __init__(self,
> data: Mapping[str, object],
There are several occurences of Dict[str, object] elsewhere. Would your
argument for dumbing down QAPIExpression apply to (some of) them, too?
Skimming them, I found this in introspect.py:
# These types are based on structures defined in QEMU's schema, so we
# lack precise types for them here. Python 3.6 does not offer
# TypedDict constructs, so they are broadly typed here as simple
# Python Dicts.
SchemaInfo = Dict[str, object]
SchemaInfoEnumMember = Dict[str, object]
SchemaInfoObject = Dict[str, object]
SchemaInfoObjectVariant = Dict[str, object]
SchemaInfoObjectMember = Dict[str, object]
SchemaInfoCommand = Dict[str, object]
Can we do better now we have 3.8?
next prev parent reply other threads:[~2023-11-23 14:13 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 1:43 [PATCH 00/19] qapi: statically type schema.py John Snow
2023-11-16 1:43 ` [PATCH 01/19] qapi/schema: fix QAPISchemaEntity.__repr__() John Snow
2023-11-16 7:01 ` Philippe Mathieu-Daudé
2023-11-16 1:43 ` [PATCH 02/19] qapi/schema: add pylint suppressions John Snow
2023-11-21 12:23 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 03/19] qapi/schema: name QAPISchemaInclude entities John Snow
2023-11-21 13:33 ` Markus Armbruster
2023-11-21 16:22 ` John Snow
2023-11-22 9:37 ` Markus Armbruster
2023-12-13 0:45 ` John Snow
2023-11-16 1:43 ` [PATCH 04/19] qapi/schema: declare type for QAPISchemaObjectTypeMember.type John Snow
2023-11-16 1:43 ` [PATCH 05/19] qapi/schema: make c_type() and json_type() abstract methods John Snow
2023-11-16 7:03 ` Philippe Mathieu-Daudé
2023-11-21 13:36 ` Markus Armbruster
2023-11-21 13:43 ` Daniel P. Berrangé
2023-11-21 16:28 ` John Snow
2023-11-21 16:34 ` Daniel P. Berrangé
2023-11-22 9:50 ` Markus Armbruster
2023-11-22 9:54 ` Daniel P. Berrangé
2023-11-16 1:43 ` [PATCH 06/19] qapi/schema: adjust type narrowing for mypy's benefit John Snow
2023-11-16 7:04 ` Philippe Mathieu-Daudé
2023-11-21 14:09 ` Markus Armbruster
2023-11-21 16:36 ` John Snow
2023-11-22 12:00 ` Markus Armbruster
2023-11-22 18:12 ` John Snow
2023-11-23 11:00 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 07/19] qapi/introspect: assert schema.lookup_type did not fail John Snow
2023-11-21 14:17 ` Markus Armbruster
2023-11-21 16:41 ` John Snow
2023-11-22 9:52 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 08/19] qapi/schema: add static typing and assertions to lookup_type() John Snow
2023-11-21 14:21 ` Markus Armbruster
2023-11-21 16:46 ` John Snow
2023-11-22 12:09 ` Markus Armbruster
2023-11-22 15:55 ` John Snow
2023-11-23 11:04 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 09/19] qapi/schema: assert info is present when necessary John Snow
2023-11-16 7:05 ` Philippe Mathieu-Daudé
2023-11-16 1:43 ` [PATCH 10/19] qapi/schema: make QAPISchemaArrayType.element_type non-Optional John Snow
2023-11-21 14:27 ` Markus Armbruster
2023-11-21 16:51 ` John Snow
2023-11-16 1:43 ` [PATCH 11/19] qapi/schema: fix QAPISchemaArrayType.check's call to resolve_type John Snow
2023-11-22 12:59 ` Markus Armbruster
2023-11-22 15:58 ` John Snow
2023-11-23 13:03 ` Markus Armbruster
2024-01-10 19:33 ` John Snow
2024-01-11 9:33 ` Markus Armbruster
2024-01-11 22:24 ` John Snow
2023-11-16 1:43 ` [PATCH 12/19] qapi/schema: split "checked" field into "checking" and "checked" John Snow
2023-11-22 14:02 ` Markus Armbruster
2024-01-10 20:21 ` John Snow
2024-01-11 9:24 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 13/19] qapi/schema: fix typing for QAPISchemaVariants.tag_member John Snow
2023-11-22 14:05 ` Markus Armbruster
2023-11-22 16:02 ` John Snow
2024-01-10 1:47 ` John Snow
2024-01-10 7:52 ` Markus Armbruster
2024-01-10 8:35 ` John Snow
2024-01-17 8:19 ` Markus Armbruster
2024-01-17 10:32 ` Markus Armbruster
2024-01-17 10:53 ` Markus Armbruster
2024-02-01 20:54 ` John Snow
2023-11-16 1:43 ` [PATCH 14/19] qapi/schema: assert QAPISchemaVariants are QAPISchemaObjectType John Snow
2023-11-23 13:51 ` Markus Armbruster
2024-01-10 0:42 ` John Snow
2023-11-16 1:43 ` [PATCH 15/19] qapi/parser: demote QAPIExpression to Dict[str, Any] John Snow
2023-11-23 14:12 ` Markus Armbruster [this message]
2024-01-10 0:14 ` John Snow
2024-01-10 7:58 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 16/19] qapi/schema: add type hints John Snow
2023-11-24 15:02 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 17/19] qapi/schema: turn on mypy strictness John Snow
2023-11-16 1:43 ` [PATCH 18/19] qapi/schema: remove unnecessary asserts John Snow
2023-11-28 9:22 ` Markus Armbruster
2023-11-16 1:43 ` [PATCH 19/19] qapi/schema: refactor entity lookup helpers John Snow
2023-11-28 12:06 ` Markus Armbruster
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=8734ww4kz4.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.