Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type checking breaks on Enum private name mangling #7619

Closed
NoahS2003 opened this issue Apr 4, 2024 · 3 comments
Closed

Type checking breaks on Enum private name mangling #7619

NoahS2003 opened this issue Apr 4, 2024 · 3 comments
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working

Comments

@NoahS2003
Copy link

NoahS2003 commented Apr 4, 2024

Type: Bug

According to the enum library docs, since Python 3.11 any attribute in an Enum with a private/mangled name will not be converted into an Enum object but will be left as an attribute. In my Python 3.12.2 interpreter, this works as expected. However, Pylance still thinks that its type will be Literal. An example where this happens looks like this:

class MyEnum(enum.Enum):
    A = 1
    B = 2
    C = 3

    __my_dict = {MyEnum.A: "ham", MyEnum.B: "spam", MyEnum.C: "egg"}

    def find_str(self):
        return self.__my_dict.get(self) # Incorrect type hint error on this line

The error produced is as follows:

Cannot access member "get" for type "Literal[MyEnum.__my_dict]"
  Member "get" is unknown

Extension version: 2024.4.1
VS Code version: Code 1.87.2 (Universal) (863d2581ecda6849923a2118d93a088b0745d9d6, 2024-03-08T15:21:31.043Z)
OS version: Darwin arm64 23.4.0
Modes:

System Info
Item Value
CPUs Apple M1 (8 x 24)
GPU Status 2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled
Load (avg) 3, 4, 4
Memory (System) 16.00GB (0.05GB free)
Process Argv --crash-reporter-id 1123edd3-4687-46ae-9d32-7507d446c5a6
Screen Reader no
VM 0%
A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:31000450
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
d34g3935:30971562
fegfb526:30981948
bg6jg535:30979843
ccp2r3:30993541
dsvsc020:30976470
pythonait:31006305
jchc7451:30973076
gee8j676:31009558
dsvsc021:30996838
gd77d436:30999572

@erictraut
Copy link
Collaborator

Could someone from the pylance team please transfer this to the pyright project?

@erictraut
Copy link
Collaborator

erictraut commented Apr 4, 2024

Thanks for the issue. I wasn't aware that private attributes were exempt. The EnumMeta metaclass seems to accumulate more and more special cases every release.

I've updated pyright's logic to reflect the runtime behavior. I've also updated the draft chapter that I recently wrote for the Python typing spec on enum type checking so it also reflects this behavior.

Interestingly, mypy also has the same bug. I've filed a bug report here.

@erictraut erictraut added bug Something isn't working addressed in next version Issue is fixed and will appear in next published version labels Apr 4, 2024
erictraut added a commit that referenced this issue Apr 4, 2024
…(mangled) names are exempted from being considered enum members. This reflects the runtime behavior. This addresses #7619.
@erictraut
Copy link
Collaborator

This is addressed in pyright 1.1.358, which I just published.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants