False error about redeclaration of Final private(double-underscore) variables

[Azureblade3808]

Environment data

• Language Server version: 2020.12.2
• OS and version: macOS Catalina 10.15.7
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.5(Anaconda)

Actual behavior

from typing import Final


class Parent:
    __a: Final[int]

    def __init__(self):
        self.__a = 0
        _ = self.__a


class Child(Parent):
    # Error: "__a" cannot be redeclared because parent class "Parent" declares it as Final
    __a: Final[int] 

    def __init__(self):
        self.__a = 0
        _ = self.__a

The code above is largely simplified and __init__ methods are there only to suppress "final but not assigned" errors and "unused" warnings.

Expected behavior

No error.

Reason

A class member named with a prefix of double-underscore and without a suffix of double-underscore is meant to be purely private. There should be no collisions between such members even if they share a same name.

[Azureblade3808]

@final private methods are OK, though there should be no needs to add @final to private methods.

[erictraut]

The behavior is correct as per PEP 591.

As confirmation, the same error is emitted by other type checkers like mypy.

[erictraut]

I think one could make the argument that PEP 591 should make an exception for class members with double-underscore names since they are obfuscated and therefore cannot conflict with same-named members in parent classes.

@gvanrossum, I'm interest in any advice you can offer here.

[Azureblade3808]

The behavior is correct as per PEP 591.

As confirmation, the same error is emitted by other type checkers like mypy.

Your are right that mypy has the same behavior.

But I'm quite confused that Final variables and @final methods are treated in different ways. As I just checked, overriding a @final method prefixed with either single-underscore or double-underscore does NOT get an error, while I believe that at least the single-underscore case deserves one.

[jakebailey]

Revisiting this, I do think there's a bug here:

In the derived class, only the double underscore prefixed things should be error-less (as they get hidden to children and are not a part of the API). I.e., __bar has an error but should not, and _foo does not have an error but should.

[jakebailey]

I know there's sort of a question as to whether or not __ should be exempt from Final (I'd argue it should), but the single underscore bit appears to be a bug.

[gvanrossum]

The __ prefix translates to name mangling (C.__foo really is a variable named _C__foo) so it really should be exempt. Agree that the single _ appears to be a bug.

[erictraut]

I've updated the logic in pyright to exempt private (double underscored) symbols from this check. @gvanrossum, you can decide whether to update PEP 591 to reflect this exemption. Also, it appears that mypy may need to also apply this fix.

I've also fixed the logic for single-underscore methods.

[gvanrossum]

I don't see why PEP 591 should be updated -- the two __foo symbols are unrelated, by virtue of the language definition for private variable name mangling.

[erictraut]

That logic makes sense, yet both pyright and mypy maintainers missed this point (or came to different conclusions) because PEP 591 didn't say anything on the topic.

[gvanrossum]

Okay, that's fair.

[jakebailey]

This issue has been fixed in version 2021.1.2, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202112-20-january-2021