Re: [PATCH v2 09/11] qapi/introspect.py: create a typed 'Annotated' data strutcure

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

> On 11/16/20 5:12 AM, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
>> 
>>> This replaces _make_tree with Annotated(). By creating it as a generic
>>> container, we can more accurately describe the exact nature of this
>>> particular value. i.e., each Annotated object is actually an
>>> Annotated<T>, describing its contained value.
>>>
>>> This adds stricter typing to Annotated nodes and extra annotated
>>> information.
>> 
>> Inhowfar?
>> 
>
> The Generic[T] trick lets us express the type of the annotated node 
> itself, which is more specific than Tuple[_something, ...etc...] and 
> this type can be preserved when we peel the annotations off.
>
> It's not super crucial, but like you say, the big benefit is the field 
> names and strict types for the special-purpose structure.

I'd lead with a brief description of the data structure you're
replacing, how we got there, and why it's ugly.  You can steal from my
review of PATCH 5.  Then explain its replacement, briefly.  And only
then talk about types.

By the time you get to types, I'm nodding along "yes, please", and will
be predisposed to accept your typing arguments at face value.

If you start with typing arguments, they have to negotiate the "yes,
please" bar all by themselves.  Harder, because Python typing stuff you
have to explain for dummies.

>>>               It also replaces a check of "isinstance tuple" with the
>>> much more explicit "isinstance Annotated" which is guaranteed not to
>>> break if a tuple is accidentally introduced into the type tree. (Perhaps
>>> as a result of a bad conversion from a list.)
>> 
>> Sure this is worth writing home about?  Such accidents seem quite
>> unlikely.
>> 
>
> We all have our phobias. I find "isinstance(x, 
> extremely_common_stdlib_type)" to be extremely fragile and likely to 
> frustrate.

You're applying programming-in-the-large reasoning to a
programming-in-the-small case.

Say you're writing a piece of code you expect to be used in contexts you
prudently refuse to predict.  The code deals with a bunch of basic
Python types.  Reserving another basic Python type for internal use may
well be unwise then, because it can make your code break confusingly
when this other type appears in input.  Which it shouldn't, but making
your reusable code harder to misuse, and misuses easier to diagnose are
laudable goals.

This is not such a piece of code.  All the users it will ever have are
in the same file of 200-something LOC.

Your commit message makes the case for your patch.  Sometimes, dropping
weak arguments strengthens a case.  I believe dropping the "It also
replaces" argument would strengthen your case.

> Maybe what's unlikely is anyone editing this code ever again. You've 
> mentioned wanting to look into changing how the schema information is 
> stored in QEMU before, so a lot of this might not matter for too much 
> longer, who knows.

Yes, I expect generating the SchemaInfoList directly would beat
generating QLitObject, then converting QLitObject -> QObject ->
SchemaInfoList.  Whether it's worth the effort is unclear.

>> For me, the commit's benefit is making the structure of the annotated
>> tree node more explicit (your first paragraph, I guess).  It's a bit of
>> a pattern in developing Python code: we start with a Tuple because it's
>> terse and easy, then things get more complex, terse becomes too terse,
>> and we're replacing the Tuple with a class.
>> 
>
> Yep.
>
>>> Signed-off-by: John Snow <jsnow@redhat.com>