mirror of https://github.com/astral-sh/ruff
130d4e1135
This eliminates the panic reported in https://github.com/astral-sh/ty/issues/909, though it doesn't address the underlying cause, which is that we aren't yet checking the types of the fields of a protocol when checking whether a class implements the protocol. And in particular, if a class explictly opts out of iteration via ```py class NotIterable: __iter__ = None ``` we currently treat that as "having an `__iter__`" member, and therefore implementing `Iterable`. Note that the assumption that was in the comment before is still correct: call binding will have already checked that the argument satisfies `Iterable`, and so it shouldn't be an error to iterate over said argument. But arguably, the new logic in this PR is a better way to discharge that assumption — instead of panicking if we happen to be wrong, fall back on an unknown iteration result. |
||
|---|---|---|
| .. | ||
| resources | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| build.rs | ||
| mdtest.py | ||
| mdtest.py.lock | ||