Can we install the latest (and avoid upgrading the version)?

Done. Fair warning that we release new pyrefly versions 1-2 times a week at the moment, so not pinning the pyrefly version may lead to ignite picking up new features (that may generate new type errors) rather often.

@rchen152 do you know why there is an error here?

train_sampler is checked above to be a DistributedSampler, which has set_epoch method: https://github.com/pytorch/pytorch/blob/d38164a545b4a4e4e0cf73ce67173f70574890b6/torch/utils/data/distributed.py#L139

This error is due to pyrefly treating the type of train_sampler as DistributedSampler | None inside the nested function, to guard against problems like this:

def f(train_sampler: DistributedSampler | None):
    if train_sampler is not None:
        def g():
            train_sampler.set_epoch(...)
        train_sampler = None
        g()  # oops! This would crash

With that said, we may be able to make this check less conservative. We have facebook/pyrefly#40 open to do some additional analysis to figure out when we can not emit this error.

@rchen152 can you please explain this error? I'm not totally sure what is read-only here.

This one took me a while to figure out! It's a bug in pyrefly (facebook/pyrefly#1803) caused by treating torch.device as a descriptor.

Same here, rather unclear what is bad-override here and below.

The bad-override error is caused by setting the type of _backend (and the type signature of spawn below) to a different type than in the ComputationModel base class. Pyrefly errors on this to prevent problems like this:

class ComputationModel:
    def __init__(self):
        self._backend: str | None = ...
class _HorovodDistModel(ComputationModel):
    def _create_from_backend(self):
        self._backend: str = ...

def clear_backend(model: ComputationModel):
    # This is accepted by a type checker because `_backend` in `ComputationModel` is annotated as `str | None`.
    model._backend = None

# This is accepted by a type checker because `_HorovodDistModel` is a subclass of `ComputationModel`.
# But it would lead to `_backend` being set to `None`, and any code in `_HorovodDistModel` that assumes
# `_backend` to be `str` would crash.
clear_backend(_HorovodDistModel())

Do you know what's wrong here?

This is down to a difference between mypy and pyrefly's type inference strategies. Mypy says that output has type List[object] because random.getstate() and torch.get_rng_state() return types with no common superclass except object, whereas Pyrefly sets the list's contained type to the union of the two types. I removed this suppression and added an explicit annotation, so that no inference is needed.

Here, I agree with pyrefly, in a follow-up PR we can put start_time before the try/except clauses.

A bit unclear what's wrong here

The text of the error message is:

`>` is not supported between `Integral` and `Literal[0]`

Interestingly, mypy emits the same error if you make it check an operation between Integral and int directly. The reason it doesn't error here seems to be that it (incorrectly) treats the code as unreachable: playground.

I see, thanks! It's true that previously we had also hard time with typing and numbers. Maybe we can safely replace the check as:

c1 = isinstance(once, int) and once > 0

Can we get rid of the ignore if we rewrite it as?

result = (
    torch.einsum("i,j,k->ijk", kernel_x, kernel_y, kernel_z)
    if ndims == 3
    else torch.einsum("i,j->ij", kernel_x, kernel_y)
)

That didn't work, unfortunately (I think the control flow was too complex for pyrefly to follow); I added kernel_z = None branches to make sure kernel_z is always defined instead.

I see, thanks! It's true that previously we had also hard time with typing and numbers. Maybe we can safely replace the check as:

c1 = isinstance(once, int) and once > 0