In Python 3.6, the argument to the register() method of a single-dispatch function (i.e. a function decorated by @functools.singledispatch) can be a 'type-like' class (pseudo-type?) from e.g. the typing module that supports isinstance().

The below demonstrates it works in Python 3.6:

$ py -3.6
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import singledispatch
>>> from typing import Sequence
>>> isinstance([1,2,3], Sequence) # 'pseudo-type' okay with isinstance
True
>>> @singledispatch
... def f(arg):
...     print('unqualified', arg)
...
>>> @f.register(Sequence) # 'pseudo-type' okay with register
... def _(arg):
...     print('sequence', *arg)
...
>>> f(1)
unqualified 1
>>> f([1,2,3])
sequence 1 2 3

This code breaks in Python 3.7:

$ py
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import singledispatch
>>> from typing import Sequence
>>> isinstance([1,2,3], Sequence) # 'pseudo-type' okay with isinstance
True
>>> @singledispatch
... def f(arg):
...     print('unqualified', arg)
...
>>> @f.register(Sequence)  # 'pseudo-type' NOT okay with register
... def _(arg):
...     print('sequence', *arg)
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Program Files\Python\Python37\lib\functools.py", line 801, in register
    f"Invalid first argument to `register()`: {cls!r}. "
TypeError: Invalid first argument to `register()`: typing.Sequence. Use either `@register(some_class)` or plain `@register` on an annotated function.

While agreeing a check on the register() arg IS required, the current check isinstance(cls, type) seems overly restrictive. This is especially true when considering the (welcome!) Python 3.7 use of annotations for single dispatch functions.

The change is not only in the added `isinstance` check:

~ $ python3.6 -q
>>> import typing
>>> isinstance(typing.Sequence, type)
True
>>>
~ $ python3.7 -q
>>> import typing
>>> isinstance(typing.Sequence, type)
False
>>>

This is why we have 4 months of betas :-)

On one hand making objects in `typing` module not classes was intentional, but on another hand this use case looks totally fine.

I would say we could update the check in `functools` to accept more things. I am however not sure what to allow here in addition to proper classes, maybe just anything that overrides `__subclasscheck__` and/or `__instancecheck__`? I could imagine there might be some other objects that implement custom instance and class checks beyond `typing` that are rejected by current checks in `functools`.

As a temporary workaround you can use `collections.abc.Sequence`, this type is aliased by `typing.Sequence`, in fact all instance checks etc. are relayed to the former.

> I would say we could update the check in `functools` to accept more things.

Could we revert abstract types in `typing` to respond True to `isinstance(..., type)` again?  I don't want singledispatch, or any other library like it, to have to special-case typing.   Especially for *non-generic* variants, responding True to `isinstance()` seems reasonable to me.  We cannot dispatch by `Sequence[int]` and some such so it makes sense for *those* to keep failing going forward.

The current suggested workaround of using abc.Sequence instead will work.

> Could we revert abstract types in `typing` to respond True to `isinstance(..., type)` again?

No, making them classes will cause significant performance penalty (I don't remember numbers now, but importing `typing` may be twice slower). Plus this will re-introduce some bugs and inconsistencies.

> I don't want singledispatch, or any other library like it, to have to special-case typing.

I didn't propose this. I proposed to allow all objects that pretend to be types but are not actually instances of `type`.

Would the enhancements to resolve this, by making singledispatch accept more things, also resolve the AssertionError from functools.singledispatch when passing it custom types, or should I raise this as a separate issue? 

------------------------------------------------
from typing import NewType, List
from functools import singledispatch

@singledispatch
def fun(arg, verbose=False):
    if verbose:
        print("Let me just say,", end=" ")
    print(arg)

MyType = NewType('MyType', List[int])

@fun.register
def _(arg: MyType , verbose=False):
    if verbose:
        print("Strength in numbers, eh?", end=" ")
    print(arg)

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-49-e549104faa9a> in <module>
      5 
      6 @fun.register
----> 7 def _(arg: MyType , verbose=False):
      8     if verbose:
      9         print("Strength in numbers, eh?", end=" ")

~/.pyenv/versions/3.7.0/lib/python3.7/functools.py in register(cls, func)
    809             argname, cls = next(iter(get_type_hints(func).items()))
    810             assert isinstance(cls, type), (
--> 811                 f"Invalid annotation for {argname!r}. {cls!r} is not a class."
    812             )
    813         registry[cls] = func

AssertionError: Invalid annotation for 'arg'. <function NewType.<locals>.new_type at 0x10fcd7730> is not a class.

+1 for this use case. Until it's resolved, perhaps there should be a note in the singledispatch docs that types from the ``typing`` module should not be used?

Reproduced on 3.11.

I've changed type because crash typically refers to segfault rather than an exception being raised.

There's no point in lamenting the compatibility with Python 3.6, it's water under the bridge. Dispatching on types like list[int] or types generated by NewType is not realistic. Maybe the only thing left to do is to raise an error on registration when the type is e.g. list[int]? Currently that passes, but then attempting to dispatch on *anything* fails with TypeError: issubclass() argument 2 cannot be a parameterized generic

Guido: Serhiy fixed this very recently in Issue46032.

The documentation should probably be improved, however, in my opinion; there's currently nothing officially stating that GenericAlias/NewType/typing aliases are unsupported.

Support for singledispatch.register(union_type) was also recently added in Issue46014, but has yet to be documented.

The original issue is about dispatching on non-parametrized generics like typing.Sequence. isinstance([], typing.Sequence) works, so it could be possible to support dispatching on typing.Sequence. But I have doubts that it is worth to revive such feature, because it needs some effort, and you can use collections.abc.Sequence instead.

But there is a conflict between using annotations in singledispatch() and MyPy (issue46191).

Let's close this issue as "won't fix" then. The solution "use collections.abc.Sequence" makes sense.

To add bit more context, there is a discussion about Python types and
annotation types, where suggestion of closing this bug has been raised

    https://github.com/python/mypy/issues/9773

The discussion is about the need of distinction between Python types and
annotation types, and explicit terminology in the documentation.

Closing this bug gives clearer indication to tools like Mypy, how to deal
with annotation types used with singledispatch.

IMHO, it is small step towards more explict Python type system, whatever
its limitations.