Sounds worth trying.

Will create a PR soon 🙂

One problem I see:

x = bool()
...
x = determine_truth()  # error

Yes, looks like this is the case.

My main motivation was the fact that I saw this code today:

if bool():   # it should have been `self.bool()` in my case
    print('trying to do something, but it is unreachable')

It was not even caught by --warn-unreachable. Changing bool() signature will make it detectable.
Probably, there are other options, which are less radical 🙂

But, here's the problem you've described:

from typing import Literal

def lit() -> Literal[False]:
    """Imagine, that this is a new `bool.__new__` constructor."""

x = lit()
...
x = bool()  # E: Incompatible types in assignment (expression has type "bool", variable has type "Literal[False]")

I think it's fine to return Literal[False] from bool(). If you have bool() with no arguments in your code, it's fine if it causes errors, because you really should use the more readable x = False instead.

We still can't make it so that bool() with no arguments is a type-checking error, because it would mean that collections.defaultdict(bool) no longer works. It calls bool() with no arguments to create values for missing dict keys.

def __new__(cls: Type[_T], __o: object) -> _T: ...

This isn't needed, because bool cannot be subclassed.

Actually, collections.defaultdict(bool) won't work if bool() returns Literal[False]. It is defined like this:

class defaultdict(Dict[_KT, _VT], Generic[_KT, _VT]):
    ...
    @overload
    def __init__(self, default_factory: Callable[[], _VT] | None) -> None: ...
    ...

So if you pass in something that returns Literal[False] when called with no arguments, the value type _VT will also be Literal[False]. It is basically the same problem as in the x = bool() example, but perhaps more likely to happen in practice.

I think it's fine to return Literal[False] from bool(). If you have bool() with no arguments in your code, it's fine if it causes errors, because you really should use the more readable x = False instead.

I fear that this change will have a lot of false positives. And types here would be inconsistent:

# 1. will have `bool` type:
a = False

# 2. will have `Literal[False]` type:
a = bool()

But, in runtime False is bool() 😞

This might cause problems for the mypy test suite, because it frequently does if bool(): to get a condition mypy doesn't understand.

Also, we shouldn't need the self type, since bool cannot be subclassed.

The mypy test suite's behaviour should be largely determined by the type fixtures, so hopefully not too bad. In any case, if this is a change we want to make, we should make it.

There are primitive types with the same logic: str() -> Literal[''], bytes() -> Literal[b''], int() -> Literal[0]. If we are going to make this, I guess it is a good idea to make this consistent across all primitives.

So, if str() will always be unreachable as well.

I had a moment to think about this problem. And it looks like we won't able to solve this without a slight modification to @overload and Literal type checking rules in mypy/etc.

So, I propose to add "weak literal" types. What are they?
Weak literal type is still a literal type with some primitive value, except it can be upcasted to its fallback type with no error.

How do we create "weak literal" types? It can be only be created when some Literal type is returned from @overload function and all other cases do return the same fallback type. Here are some example:

def some() -> Literal[False]: ...

s = some()  # Literal[False, weak=False]
s = True  # error

class bool:
  @overload
  def __init__() -> Literal[False]: ...
  @overload
  def __init__(arg) -> 'bool': ...  # `Literal[False]` has `bool` as a fallback type, so it is considered "weak"

b = bool()  # Literal[False, weak=True]
b = True  # ok

class other:
  @overload
  def __init__() -> Literal[False]: ...
  @overload
  def __init__(arg) -> str: ...  # `Literal[False]` is not compatible with `str`, literal is strong

o = other()  # Literal[False, weak=False]
o = True  # error

What do you think?

I'm not aware of any use cases for non-weak literals, so I mostly see this as an annoying "feature" of mypy.

Reading through this and searching around.. I wonder if this would be a mypy feature?

Enum actually has it already:

from enum import Enum


class MyBool(Enum):
    TRUE = True
    FALSE = False


reveal_type(MyBool.TRUE)  # Revealed type is "Literal[test.MyBool.TRUE]?"
x = MyBool.TRUE
reveal_type(x)  # Revealed type is "test.MyBool"

Based on some searching I think this behavior is related to tracking last_known_value within mypy.

So mypy would need to know that bool() returns a bool type with last known value of Literal[False] which would be acceptable as a literal, but would not coerce any variable created from it to be a literal.