KotlinIsland / KotlinIsland/basedmypy

Don't allow `<nothing>` to suppress unreachable errors

Open
#246 1 comment 1 reaction 0 assignees View on GitHub
feature p-2
Dominant language
Python
Stars
202
Forks
6
PR merge metrics
No merged PRs in 30d

Description

```py
def foo(data: list[str]):
if data is None:
print("hi") # error, unreachable
if data is None:
raise Exception # no error
```

Due to the unsoundness of Pythons runtime, mypy allows `raise` and other `` forms to suppress "unreachable" errors to allow for a smooth way to validate types and data dynamically.

I don't like this as you could:
- run into situations where you unintentionally create a `` on an unreachable line
- have dead code lying around that is no longer needed.

I don't know what the best way to handle this is though, as there would be no way to detect if the code in question is dead or intentional.

### Additional ramblings
Ideally there should be a special error type for this exact purpose, with hard and soft checks depending of if it's syntactically or type-based unreachable:
```py
class UnreachableAssertion(AssertionError):
"""Used to indicate when a branch should be unreachable."""
pass
```
```py
assert False
message = "among"
assert_unreachable(message) # type-based unreachable, no error
raise UnreachableAssertion(message) # syntax based unreachable, no error
raise UnreachableAssertion(message) # error, absolutely unreachable
```
```py
assert True
raise UnreachableAssertion(message) # error, statement is reachable
```

Or maybe that is over-engineering a problem that doesn't exist, maybe just only special casing `assert_never` is enough.

Contributor guide

Open the contributing guide

Research direction

The issue names no files or tests; start by locating the unreachable-error handling and the existing treatment of `raise`, `assert_never`, and other `` forms. Done should be a settled rule for these cases, with regression coverage for the examples in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.