qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 0/6] qapi: static typing conversion, pt5c


From: John Snow
Subject: Re: [PATCH v4 0/6] qapi: static typing conversion, pt5c
Date: Tue, 21 Feb 2023 12:32:23 -0500



On Tue, Feb 21, 2023, 1:42 AM Markus Armbruster <armbru@redhat.com> wrote:
John Snow <jsnow@redhat.com> writes:

> On Wed, Feb 15, 2023 at 8:39 AM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> I had a few suggestions, but none of them requires a respin.  Let's
>> discuss them, and then I merge.
>
> Hiya, I lost track of things a little due to the other Python
> discussion. Who is waiting for whom?

Just two questions remain:

* PATCH 3: Dumb down check_keys() argument all the way to List[str]?

Kinda prefer not to, but maybe I'm being too precious. (I have some more exploratory patches that do use tuples here instead, but admit it's not crucial.)

From a pure typing perspective, I wish I could leave it as it is now, because I prefer to type input types as loosely as possible: claim only the minimum power we need, instead of enforcing the specificity we happen to have.

With the bug for 3.6 that is forcing me to use a more specific type anyway, maybe you're right and I should just use List[] until I'm allowed to have my proper abstraction.

OK, before I go further, lemme say that you can change it to List[] if you want. I won't be too precious about it. (You can rewrite the patch in question if you don't want to wait 24h.)

But, a question about typing strategy:

As a python tooling maintainer, should I push people to type as flexible as possible or as *specific* as possible in general?

Flexible: (e.g. Sequence or Iterable)
- More likely to get along with other code
- More "pythonic", abstractly
- Less useful as documentation; if a function always happens to get a list, is it annoying to pretend it's merely a sequence?

Specific: (e.g. List)
- Most useful as documentation
- Can assert greater knowledge of all callers
- More power afforded to function ("room to grow"?)
- More likely to require non-local edits when changing functionality or refactoring
- More likely to require "casts" at callsites to convert data types

I think I lean towards the flexible/broad typing strategy in general, but lament it cannot be applied appropriately here today.


* PATCH 4: Suggested commit message addition okay?

Yes, ACK.


We settle them, and then I'll take it from there.


reply via email to

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