This is a meta-issue for problems caused by isinstance(list[int]) returning True.

See also discussion in issue45438.

isinstance(x, type) returns True for instances of types.GenericAlias (like list[int]). While it may help in some cases related to typing, in many unrelated cases it causes problems if the value which is not a type passes checks for types.

Also, isinstance(x, type) been not equal to issubclass(type(x), type) can cause other problems. No matter what the result should be, it should be consistent.

There are many occurrences of isinstance(..., type) in the code.

$ find Lib -name '*.py' \! -path '*/test*' -exec egrep 'isinstance.*,
type\)' '{}' + | wc -l
55

And all of them can potentially be broken if pass a types.GenericAlias instance. Many of them are safe, but every case should be analyzed.

One thing that probably should be considered in this context:

isinstance(arg, type) == issubclass(type(arg), type)

Holds True for arg in (Optional[X], Union[X, Y]). Both sides evaluate to False. (v3.10.0)

While I still think both sides evaluating to True would be more intuitive, this supports the proposed change.

Small test snippet:

```
from typing import Dict, List, Set, Tuple, Optional, Union

import pytest


@pytest.mark.parametrize('arg', [
    list, List[int], list[int],
    dict, Dict[str, int], dict[str, int],
    set, Set[int], set[int],
    tuple, Tuple[str, int], tuple[str, int],
    Optional[int],
    Union[int, str]
])
def test_invariant(arg):
    same = isinstance(arg, type) == issubclass(type(arg), type)
    result = "Check" if same else "Failed"
    print(f"\n{result}: Testing: {arg=} with {type(arg)=}: {isinstance(arg, type)=} <> {issubclass(type(arg), type)=}")
    assert same

```

Any other commonly used annotations that could be added to the checklist?

Sorry for the noise: 
- Literal['a', 'b'],
- TypeVar('T')
Behave like Optional/Union

#46032 is related to this issue.

See https://github.com/python/mypy/issues/9773#issuecomment-1000975000. I may have talked myself into agreeing with Serhiy there! It does seem inconsistent that Any is not considered a type but list[int] is:

>>> isinstance(list[int], type)
True
>>> import typing
>>> isinstance(typing.Any, type)

There is also https://bugs.python.org/issue44293 about inspect.isclass

> It does seem inconsistent that Any is not considered a type but list[int] is

Yeah, almost none of the typing "types" are types ever since PEP 560. Issue45755 was a side effect too.

So is it too late to change this? This went out with 3.10, Serhiy has argued it's a bugfix.

`isinstance(list[int], type)` returns `True` in 3.9 as well, so the behaviour has been around for a while. (Not a comment on whether the change is worth making, just a note.)

Okay, so it is probably here to stay. We could justify it (after the fact :-) by saying that you can instantiate list[int], but not Any.

Are there exceptions to that? (I.e. are there other annotation types that have isinstance(X, type) return False but can be instantiated, or the other way around?)

My plan was to fix as much bugs in the stdlib and backport workaround to 3.9 and 3.10, then propose to revert this "feature" in 3.11.

There is a risk of introducing some regressions by this change, but we can handle it. I think it is better to do it now and fix potential bugs in third-party code (we cannot add workarounds in all third-party code) than keep this weird special case forever.

Yes, there are a few exceptions to that :(

```
>>> from typing import Annotated
>>> x = Annotated[int, "idk some int"]
>>> x()
0
>>> isinstance(x, type)
False
>>>
>>> from re import Pattern
>>> y = Pattern[str]
>>> y()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 're.Pattern' instances
>>> isinstance(y, type)
True
```

I agree with Serhiy.

I now agree with Serhiy's plan. We should execute ASAP so people get a chance to try this in the next alpha release.

We will still allow instantiating e.g. list[int], right?

Gentle ping, as the next alpha will be release soon

> We will still allow instantiating e.g. list[int], right?

I certainly hope so! That would be a much more breaking change if we were to change that, and I can't personally see any benefit to doing so.