lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 29 Oct 2020 22:24:46 -0700
From:   Daniel Latypov <dlatypov@...gle.com>
To:     David Gow <davidgow@...gle.com>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH] kunit: tool: fix pre-existing python type annotation errors

On Thu, Oct 29, 2020 at 7:56 PM David Gow <davidgow@...gle.com> wrote:
>
> On Thu, Oct 22, 2020 at 6:08 AM Daniel Latypov <dlatypov@...gle.com> wrote:
> >
> > The code uses annotations, but they aren't accurate.
> > Note that type checking in python is a separate process, running
> > `kunit.py run` will not check and complain about invalid types at
> > runtime.
> >
> > Fix pre-existing issues found by running a type checker
> > $ mypy *.py
> >
> > All but one of these were returning `None` without denoting this
> > properly (via `Optional[Type]`).
> >
> > Signed-off-by: Daniel Latypov <dlatypov@...gle.com>
> > ---
>
> I'm not going to pretend to really understand python annotations
> completely, but this all seems correct from what I know of the code,
> and I was able to install mypy and verify the issues were fixed.
>
> Clearly, if we're going to have type annotations here, we should be
> verifying the code against them. Is there a way we could get python
> itself to verify this code when the script runs, rather than have to
> use mypy as a tool to verify it separately? Otherwise, maybe we can

Type annotations are https://www.python.org/dev/peps/pep-0484/
There isn't support for python itself to type check and it calls out
(only) mypy by name as a type-checker.

I don't have a good answer for how we prevent them from bitrotting :/

> run it automatically from the kunit_tool_test.py unit tests or
> something similar?

I don't think it's possible to do so cleanly.

E.g. I don't know python that well, but here's my guess at what it'd
have to look like:
* We have to assume mypy is installed
* dynamically loading the module inside a `try` (so we don't break
users who don't have it)
* figure out what func is the entry point to mypy and call it on
"./kunit.py" somehow

>
> Regardless, this is
>
> Reviewed-by: David Gow <davidgow@...gle.com>
>
> Cheers,
> -- David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ