[libvirt PATCH v2 4/6] ci: Introduce a util module

Erik Skultety eskultet at redhat.com
Wed Mar 17 17:40:43 UTC 2021


On Wed, Mar 17, 2021 at 06:11:32PM +0100, Andrea Bolognani wrote:
> On Wed, 2021-03-17 at 18:05 +0100, Erik Skultety wrote:
> > On Wed, Mar 17, 2021 at 05:06:33PM +0100, Andrea Bolognani wrote:
> > > I don't know how to express that in terms of Python types
> > > (List[Dict[str, Any]]?), and I'm concerned by the fact that changing
> > > the return type to something obviously wrong like "int" results in
> > > zero observable changes.
> > 
> > I'd suggest List[Dict] to be enough in this case since. We can safely assume
> > the returned JSON will always be a list of objects, the rest is on the caller.
> 
> I trust your expertise here :)
> 
> > > How are type hints enforced? Do we need to turn that on somehow?
> > 
> > They're not. Python will always remain a dynamically typed language. The whole
> > point of type hinting is for static analysis via 'mypy' and for various IDEs
> > that can actually make use of those as well during completion which is nice.
> > (I'm wondering whether the jedi vim plugin is capable of reading those too)
> 
> I see. It would be nice to run mypy in 'check' mode (assuming that
> exists) at syntax-check time, similarly to what we already do with
> flake8. That can come later, though.

One more thing, what is the Python 3.<minor> acceptance policy for scripts? I
mean we expect the scripts to work with 3.X as we declare on libvirt.org, but
f-strings for example are 3.6+ and 3.9 essentially makes the typing module
deprecated since it integrated most of the hints to standard collections [1],
IOW instead of writing "List[Dict[type, type]]" you can now use the standard
containers for that as well: "list[dict[type, type]]" without importing
anything, so basically the list/dict builtin can serve as both container
constructors as well as static type hints.

Erik

[1] https://www.python.org/dev/peps/pep-0585/




More information about the libvir-list mailing list