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

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/lib...>) > > 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?

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?