[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 08/14] qapi/introspect.py: create a typed 'Annotated' data
Re: [PATCH v4 08/14] qapi/introspect.py: create a typed 'Annotated' data strutcure
Thu, 04 Feb 2021 16:37:45 +0100
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Eduardo Habkost <firstname.lastname@example.org> writes:
> On Wed, Feb 03, 2021 at 03:47:36PM +0100, Markus Armbruster wrote:
>> John Snow <email@example.com> writes:
>> > Presently, we use a tuple to attach a dict containing annotations
>> > (comments and compile-time conditionals) to a tree node. This is
>> > undesirable because dicts are difficult to strongly type; promoting it
>> > to a real class allows us to name the values and types of the
>> > annotations we are expecting.
>> > In terms of typing, the Annotated<T> type serves as a generic container
>> > where the annotated node's type is preserved, allowing for greater
>> > specificity than we'd be able to provide without a generic.
>> > Signed-off-by: John Snow <firstname.lastname@example.org>
>> > +class Annotated(Generic[_NodeT]):
>> > + """
>> > + Annotated generally contains a SchemaInfo-like type (as a dict),
>> > + But it also used to wrap comments/ifconds around scalar leaf values,
>> > + for the benefit of features and enums.
>> > + """
>> > + # Remove after 3.7 adds @dataclass:
>> Make this
>> # TODO Remove after Python 3.7 ...
>> to give us a fighting chance to remember.
>> > + # pylint: disable=too-few-public-methods
>> > + def __init__(self, value: _NodeT, ifcond: Iterable[str],
>> > + comment: Optional[str] = None):
>> Why not simply value: _value?
> x = C(1)
> y: C[int]
> y = C('x') # mistake
> Declaring value as _NodeT does:
> - Make the inferred type of x be Annotated[int].
> - Catch the mistake above.
I smell overengineering. I may well be wrong.
Without doubt, there are uses for using the type system for keeping
SomeGenericType[SomeType] and SomeGenericType[AnotherType] apart.
But what do we gain by keeping the Annotated[T] for the possible T
_tree_to_qlit() doesn't care: it peels off the wrapper holding ifcond
and comment, and recurses for the JSON so wrapped. Regardless of what
was wrapped, i.e. what kind of T we got.
Heck, it works just fine even if you wrap your JSON multiple times. It
doesn't give a hoot whether that makes sense. Making sense is the
So what does care?
Or am I simply confused?
PS: As far as I can tell, _tree_to_qlit() doesn't give a hoot whether a
dictionary's values are wrapped, either.
[PATCH v4 10/14] qapi/introspect.py: improve readability of _tree_to_qlit, John Snow, 2021/02/02
[PATCH v4 09/14] qapi/introspect.py: improve _tree_to_qlit error message, John Snow, 2021/02/02
[PATCH v4 11/14] qapi/introspect.py: add type hint annotations, John Snow, 2021/02/02