Alternative syntax for unions requires Python 3.10 or newer

[stolenzc]

Envirement data

• pylance version: 2020.10.2
• vscode version: 1.50.1
• python version: 3.8.5
• Djagno version: 3.0.3
• OS platform: MacOs 10.15.7

My django program also alert this and I don't know why, I want to know why and how to ignore this warning?

[Zajozor]

Experiencing the same issue, pylance version: 2020.10.2 (pyright d6db7c90), Python 3.7, Django 2.2

Same as the op, we are using Django Rest Framework.

The permission classes which contain the | between them inherit from this class

@six.add_metaclass(BasePermissionMetaclass)
class BasePermission(object):
    """
    A base class from which all permission classes should inherit.
    """

    def has_permission(self, request, view):
        """
        Return `True` if permission is granted, `False` otherwise.
        """
        return True

    def has_object_permission(self, request, view, obj):
        """
        Return `True` if permission is granted, `False` otherwise.
        """
        return True

Further related code can be found at https://github.com/encode/django-rest-framework/blob/master/rest_framework/permissions.py#L97 and near that.

Even manually adding a metaclass with defined __or__ property to the Permission classes does not remove the pylance error. Please let me know if further information is required.

[erictraut]

Thanks for the bug report. I've updated the logic so it detects the case where a class has a custom metaclass that supports the __or__ or __ror__ method and use that for the | operator rather than assuming a misuse of of PEP 614 prior to Python 3.10. This fix will be in the next version of pylance.

[cdce8p]

@erictraut The | operator for type annotations won't be exclusive to 3.10, since postponed evaluation of annotations is enough to support it, as long as the type checker understands it. It can even be used in type comments with Python 2. python/typing#429 (comment) and python/mypy#9647

It might be an idea to limit the warning to isinstance and issubclass calls, or check if from __future__ import annotations is used with type annotations.

[erictraut]

@cdce8p, that's a good point. I've changed the code to suppress that error in any situation where the evaluation of the type annotation is postponed (within quotes and with from __future__ import annotations enabled). The diagnostic will still be reported in cases where you're using <3.10 and the evaluation is not postponed (e.g. in a type alias declaration or an isinstance call).

[jakebailey]

This issue has been fixed in version 2020.10.3, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#2020103-28-october-2020

[Zajozor]

@jakebailey The problem is not fixed in 2020.10.3

[Info  - 9:19:46 AM] Pylance language server 2020.10.3 (pyright b881f28d) starting

The specific class is from DRF ( details in my comment above ).

Should I create a new issue, or can we reopen this?
Thank you.

[cdce8p]

Same with type annotations. It seems mostly fixed, however I'm encountering a wired edge case with . notation.
E.g. time | None works, whereas dt.time | None dosen't.

[erictraut]

@Zajozor, the case involving the Django Permission class will require an update to the Django type stubs so the metaclass declaration properly reflects the fact that it supports a custom __or__ overload method. Please file a separate issue on this, since it's a different issue from the type checker logic.

@cdce8p, I'm able to repro this problem in pylance but not in pyright, which is strange. I suspect it's related to the semantic token highlighting implemented in pylance. I'll investigate further.

[erictraut]

@cdce8p, I found the root cause of the problem you reported. As I suspected, it was a bad interaction between the semantic token provider and the type evaluator. When the semantic token provider asks the type evaluator "what is the type of this token?", there are cases where we need to walk up the parse tree and evaluate the expression in a broader context. In this case, for example, we need to evaluate the entire type annotation expression so we know that the expression has a postponed evaluation.

The fix is in place, and it will be included in the next release.

[cdce8p]

@erictraut Thanks for spending the time investigating and fixing the issue 👍

[jakebailey]

This issue has been fixed in version 2020.11.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#2020110-4-november-2020

[hassanselim0]

For those wondering about the DRF Stubs issue, a very temporary fix is it edit your stubs locally, just go to rest-framework-stubs/permissions.pyi:34 (or just "Go to Definition" of BasePermission) and replace this:
class BasePermission(object):
with this:
class BasePermission(object, metaclass=BasePermissionMetaclass):
Everything else is already there, the metaclass itself is in the stub and it properly inherits from OperationsHolderMixin which has the __or__ method defined.

[cdce8p]

@erictraut There still seems to be an issue when using more the two types.

from __future__ import annotations
var: int | str | list | None = None

This would be a valid syntax: https://www.python.org/dev/peps/pep-0604/#simplified-syntax

[erictraut]

@cdce8p, this is a different issue. You're using annotations future with a version of Python older than 3.10. This will be fixed in the next release.

[ahnafalnafis]

@erictraut The | operator for type annotations won't be exclusive to 3.10, since postponed evaluation of annotations is enough to support it, as long as the type checker understands it. It can even be used in type comments with Python 2. python/typing#429 (comment) and python/mypy#9647

It might be an idea to limit the warning to isinstance and issubclass calls, or check if from __future__ import annotations is used with type annotations.

Thank you soo much!!! This worked for me!