[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 02/16] qapi/expr.py: Check for dict instead of OrderedDict

From: Markus Armbruster
Subject: Re: [PATCH v3 02/16] qapi/expr.py: Check for dict instead of OrderedDict
Date: Thu, 25 Feb 2021 11:40:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

John Snow <jsnow@redhat.com> writes:

> On 2/24/21 4:30 AM, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
>>> OrderedDict is a subtype of dict, so we can check for a more general
>>> form. These functions do not themselves depend on it being any
>>> particular type.
>> True.  The actual arguments can only be OrderedDict, though.  I think we
>> refrained from relaxing to dict in these helpers because we felt
>> "staying ordered" is clearer.
> As a habit, I tend towards declaring the least specific type possible 
> for input and declaring the most specific type possible for output.

This maximimizes generality, which can be quite worthwhile.  Maximizing
generality by default is not a bad habit, I guess.  But cases exist
where generality is not needed, and other considerations take

>> We're *this* close to mooting the point, because
>>      Changed in version 3.7: Dictionary order is guaranteed to be
>>      insertion order. This behavior was an implementation detail of
>>      CPython from 3.6.
>> https://docs.python.org/3.7/library/stdtypes.html
>> Is messing with it necessary for later work?  If not, is it a worthwhile
>> improvement?
> Not strictly necessary, but if the expression checkers here don't 
> *require* the type be an ordereddict, why bother to enforce that here?
> It's just a bid to slacken the type (my type hints will look for Dict, 
> not OrderedDict) and leave the use of OrderedDict as an "implementation 
> detail" that only parser.py knows about.

"Orderedness" is anything but a detail only parser.py knows about.


    { 'command': 'blockdev-insert-medium',
      'data': { 'id': 'str',
                'node-name': 'str'} }


    OrderedDict([('command', 'blockdev-insert-medium'),
                  OrderedDict([('id', {'type': 'str'}),
                               ('node-name', {'type': 'str'})]))])

For the inner dictionary, order matters, because the difference between

    void qmp_blockdev_insert_medium(const char *id, const char *node_name,
                                    Error **errp);


    void qmp_blockdev_insert_medium(const char *node_name, const char *id,
                                    Error **errp);


For the outer dictionary, order carries no semantic meaning.

My point is: parser.py fundamentally builds *ordered* dicts.  We're
certainly free to relax them to more general types wherever
"orderedness" is not needed.  However, one of the main aims of this
typing exercise is to make the code easier to read, and I doubt making
things more general helps there.

Related: the type aliases for the AST you define later in this series.
I figure relaxing these to more general types where possible would
actually reduce their value.  TopLevelExpression tells me more than

I'm not against relaxing types per se.  Judicious relaxation is often
useful to keep code more generally useful.  When to relax isn't always

> (I needed to change it for prototyping using an off-the-shelf parser, so 
> it was annoying to have it check for a stronger type if it doesn't 
> absolutely have to.)

If your off-the-shelf parse doesn't preserve order, it's not fit for the
purpose :)

>>> Signed-off-by: John Snow <jsnow@redhat.com>
>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>> Reviewed-by: Cleber Rosa <crosa@redhat.com>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]