Type hint sybil/example.py

[adamtheturtle]

This makes mypy --strict sybil/example.py pass.

[adamtheturtle]

I think mypy doesn't like checking truthiness of a function:

sybil/example.py:62: error: Function "evaluator" could always be true in boolean context  [truthy-function]

[cjw296]

Function "evaluator" could always be true in boolean context is a pretty crappy message :-(
Do you have a link to the mypy docs on what it's sad about here?

The change is needlessly wordy and makes me sad about appeasing mypy's inadequacies :-(

[adamtheturtle]

The error was related to https://mypy.readthedocs.io/en/stable/error_code_list.html#check-that-function-isn-t-used-in-boolean-context-truthy-function, because self.document.evaluator was typed as an Evaluator.
I have changed it to be correctly typed as an Optional[Evaluator], and therefore been able to revert the change which made you sad.

That said, we will hit into related problems with self.document.evaluator later, as mypy does not allow assigning to a method:

from typing import Callable, Optional

class Example:
    def __init__(self) -> None:
        # mypy gives "error: Cannot assign to a method  [method-assign]" for this.
        self.foo: Optional[Callable[[], None]] = None

    def foo(self) -> None:
        pass

I think that in order to satisfy mypy, we will either have to add type: ignore s (which I try to avoid, where possible), or change document to be more complex in some ways (likely having another variable to track whether the evaluator should be used).

[cjw296]

That "can't assign to a method" feels like a straight up bug in mypy, no?
I'm guessing this problem has come up with other folks attempting to add type hints to existing code of this type?

[adamtheturtle]

That "can't assign to a method" feels like a straight up in mypy, no?

I'm not sure what that means

[adamtheturtle]

There are many discussions on this - with many people wanting mypy to support assigning to a method. See python/mypy#708 for an example.

I do not get the impression that very soon there will me a mypy change to accommodate. You can even see an issue raised by me in 2018 when I wanted to assign to a method precisely as described in the Python documentation: python/mypy#5062 (comment).

In a follow-up PR, I think we will have to decide either to change document, to add a type: ignore, or to ignore all method-assign errors.

[cjw296]

Can this check be disabled in mypy's config file? Failing that, how many type: ignore comments are we talking about? :sigh:

[adamtheturtle]

Can this check be disabled in mypy's config file?

Yes, that's what I meant when I said: "or to ignore all method-assign errors.".

Any specific mypy error code can be ignored in mypy's config file.

[cjw296]

Okay, let's do that... Might be worth getting a branch going that has mypy turned on and rebase that onto master as more PRs land.

(ie: just the CI, so we know where we're at and what config we'll be using...)

That said, how hard would it be to use pyright instead of mypy? I think @hynek has had some success with this?

[adamtheturtle]

@cjw296 I'm happy to do those tasks. I think they're best as follow-ups, as this change doesn't yet hit the problem:

• Add mypy to CI, with pypyoject.toml level ignores for files which are not yet compliant
• Address the method-assign error. From this conversation, most likely by globally ignoring that error type. I will look into that further in the follow-up, in case there are complications I have not considered here.
• Look into adding pyright (potentially as a replacement for mypy). I will say that in my own projects, I use both pyright and mypy, and I have found roughly equal numbers of annoyances. I like having both as, despite annoyances, they each have caught a few bugs that the other has not.

[hynek]

I wouldn’t call my experience with pyright “successful”. 😅 I’m trying to make my packages compatible with it, but they’re actively being the opposite of nice towards me and attrs so I do it rather begrudgingly.