"error: 'type' expects no type arguments, but 1 given" if type is aliased to another name

[johnpmcconnell]

Bug Report

With the implementation of PEP 585 in Python 3.9, type now accepts a generic parameter. This makes typing.Type obsolete, reflected in its deprecation.

However, if the type built-in is assigned to another name and then used in a type declaration, mypy produces an error.

This does not occur with other types affected by PEP 585, or at least not all of them. I can confirm list and dict do not exhibit this behavior.

To Reproduce

Example code file:

generictype.py

Type = type

class MyInt(int):
    pass

x_type: Type[int] = MyInt

1. Install mypy into a Python 3.9 environment.
2. Execute mypy against the script: mypy .\generictype.py. No arguments or configuration are required.

Expected Behavior

This should result in a success run with no errors:

> mypy .\generictype.py
Success: no issues found in 1 source file

Actual Behavior

mypy identifies an error:

> mypy .\generictype.py
generictype.py:3: error: "type" expects no type arguments, but 1 given
Found 1 error in 1 file (checked 1 source file)

Also note that using x_type: type[int] = MyInt directly eliminates the error.

Your Environment

• Mypy version used: mypy 0.800
• Mypy command-line flags: None
• Mypy configuration options from mypy.ini (and other config files): None
• Python version used: Python 3.9.1 (inside a venv)
• Operating system and version: Windows 10

Motivation

My actual code doesn't look exactly like the reproducing code above. I encountered it trying to make my code backwards compatible with Python 3.7+. My real usage looks more like this:

from __future__ import annotations

if sys.version_info >= (3, 9):
    List = list
    Type = type
else:
    # Legacy generic type annotation classes
    # Deprecated in Python 3.9
    # Remove once we no longer support Python 3.8 or lower
    from typing import List
    from typing import Type

class MyCustomContext:
    data: List[int]

    def __init__(self):
        self.data = []

    def __enter__(self) -> MyCustomContext:
        return self

    def add(i: int) -> None:
        self.data.append(i)

    def __exit__(
        self,
        ex_type: Optional[Type[Exception]],
        ex_value: Optional[Exception],
        ex_traceback: Optional[TracebackType],
    ) -> None:
        if ex_value is None and len(self.data) > 100:
            raise ValueError('Too much data')

For the time being, I can work around this by just continuing to use typing.Type, but I'd like to eliminate this deprecated class.

[johnpmcconnell]

So I believe this is caused by the aliasing behavior, where assigning a generic type causes mypy to automatically assume the free variables are Any. (I discovered this after encountering #8715.)

Since the problem is the assignment, there's a fairly simple workaround: import with an alias instead of assigning it.

So this fixes it:

from builtins import type as Type

class MyInt(int):
    pass

x_type: Type[int] = MyInt

Or in the realistic context:

from __future__ import annotations

if sys.version_info >= (3, 9):
    from builtins import list as List
    from builtins import type as Type
else:
    # Legacy generic type annotation classes
    # Deprecated in Python 3.9
    # Remove once we no longer support Python 3.8 or lower
    from typing import List
    from typing import Type

Maybe the documentation could be updated to specifically mention this work around if the automatic Any isn't desired?

---

I'm not sure what motivated the desire to silently assume the free variables are Any, but I think this demonstrates the behavior is unexpected and confusing. It might also be worth thinking about deprecating that automatic behavior, possibly with an option to disable it in the mean time. It certainly wouldn't be hard to provide the free variables explicitly if that's what the author intended:

Something = type[Any]

I would write that anyway if it's what I actually meant.

[abravalheri]

Well said @johnpmcconnell. If we go back to the Zen of Python:

Explicit is better than implicit.

And this unexpected, implicit behaviour can be definitely confusing and error-prone, as demonstrated in #8715.

[johnpmcconnell]

@abravalheri I think even more apt is,

In the face of ambiguity, refuse the temptation to guess.

[JacobHayes]

This also arises when a class has a type attribute that shadows the builtin, for example:

from __future__ import annotations

class Foo:
    foo: type[Foo]

_type = type

class Bar:
    type: int
    foo: _type[Foo] = Foo  # error: "type" expects no type arguments, but 1 given

All of the other code can happily use the py 3.9+ style type[...], so the extra import proposed above is a bit more out of place (but probably the workaround I'll use for now 😁).

[AlexWaygood]

FYI, the workaround typeshed currently uses for this bug is to do from builtins import type as Type at the top of the module, instead of doing type = Type

[johnpmcconnell]

@JacobHayes In that use case, I would suggest renaming the attribute. Shadowing built-ins is generally a bad idea. The standard lib suffixes names with underscores when avoiding a built in name is too difficult (so type_ in your example), but it's likely that you could add information to the attribute name in your case to make it more unique (so something like customer_type if it's describing customers).

[AlexWaygood]

The standard lib suffixes names with underscores when avoiding a built in name is too difficult (so type_ in your example).

FWIW, while I agree that this is best practice, it often isn't followed, even in the stdlib, even in relatively new modules such as dataclasses.