Re: [python] WIP-FYI: mypy annotations for libvirt-python and cleanup for generator.py

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

 



On Mon, Apr 20, 2020 at 07:21:10AM +0200, Philipp Hahn wrote:
> Hello,
> 
> Am 08.11.18 um 11:11 schrieb Philipp Hahn:
> > Maybe you already have heard about mypy <http://mypy-lang.org/>, which
> > "is an experimental optional static type checker for Python that aims to
> > combine the benefits of dynamic (or "duck") typing and static typing".
> > 
> > I started to write a manual annotation file for the Python binding of
> > libvirt. I've attached my current version, so others can benefit from
> > it, too. It is far from complete, but it already helped my to find some
> > errors in my code.
> > (My latest version is also available at
> > <https://github.com/univention/typeshed/blob/libvirt/third_party/2and3/libvirt.pyi>)
> > 
> > Long-term it probably would be better to teach the Python binding
> > "generator.py" to add the type information (PEP 484
> > <https://www.python.org/dev/peps/pep-0484/>) directly into the generated
> > "libvirt.py" file, but that's for another day.
> > If someone else is interested in helping with that, please feel free to
> > get in contact.
> 
> This project got postponed for a long time, but I have a first working
> version in my git branch at
> <https://github.com/univention/libvirt-python/tree/typing>.
> It is not perfect and ready for merging yet, but generated a first
> working version. Here's an example:
> 
> > def qemuMonitorEventRegister(conn,  # type: virConnect
> >                              dom,  # type: virDomain
> >                              event,  # type: str
> >                              cb,  # type: Callable[[virConnect, virDomain, str, int, int, str, _T], None]
> >                              opaque,  # type: _T
> >                              flags=0  # type: int
> >                              ):  # type: (...) -> int
> 
> 1. There are 2 mypy syntax's for doing the typing annotation: This first
> one adds special comments and also works with Python 2:
> 
> > def function(name, age):  # type: (str, int) -> bool
> 
> The second version only works since python 3.5:
> 
> > def function(name: str, age: int) -> bool:
> 
> As Python 2 is EOL, "generator.py" already uses Python 3 and Python 2
> support was already removed, what is the minimum version of Python 3
> required by libvirt-python? That is, should I use the old "comment"
> variant or directly the new "inline" variant?

We've only documented >= 3.0, but given our supported build platforms
we can make that >= 3.5, so I sent a patch todo that.

> 2. Actually the branch contains many cleanup patches and even some error
> fixes, which could go into master right now. How can I best accomplish
> that? Build a 2nd branch with only those fixes and send the patch queue
> to the mailing list?

Yes, if you've found & fixed bugs, I'd strongly recommend sending those
fixes as a standalone patch series as soon as you like.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux