Issue using `rna_enums` module (PylancereportPrivateImportUsage)

[Andrej730]

VS Code, Pylance is giving errors trying to use enums from rna_enums module, see an example below.

import bpy
from typing import TYPE_CHECKING

if TYPE_CHECKING:
    import bpy._typing.rna_enums as rna_enums


class SimpleOperator(bpy.types.Operator):
    bl_idname = "wm.simple_operator"
    bl_label = "Simple Operator"

    # OperatorReturnItems" is not exported from module "bpy._typing.rna_enums" PylancereportPrivateImportUsage
    # (type) OperatorReturnItems = Literal['RUNNING_MODAL', 'CANCELLED', 'FINISHED', 'PASS_THROUGH', 'INTERFACE']
    def execute(self, context) -> set["rna_enums.OperatorReturnItems"]:
        print("Hello from the simplest operator!")
        return {"FINISHED"}


# Register the operator
bpy.utils.register_class(SimpleOperator)

[JonathanPlasse]

I have found no resources on this.
I looked at:

• https://docs.python.org/3/reference/simple_stmts.html#type
• https://github.com/microsoft/pyright/issues?q=is%3Aissue%20reportPrivateImportUsage%20

You could open an issue with an minimal reproducible example to ask if this intended or a bug on Pyright Github issues, and how to fix it.

[nutti]

I think this issue is not related to only for fake-bpy-module.
Please check if this issue also happens with non fake-bpy-module environment.

[Andrej730]

I was able to reproduce it by creating a new package and using the snippet below:

import test_site_package.xxx as t
import test_site_package._xxx as _t
t.OperatorReturnItems # Fine.
_t.OperatorReturnItems # Error.

And I've found why it occurs now - it's a long thread (microsoft/pyright#10248) but the current situation is expained here - microsoft/pyright#9008 (comment)

TLDR:

• Since 1.1.398 pyright started to report usage of modules that started with _, as in _typing in our case as those modules are considered private.
• Currently the change is temporarily reverted (presumably for a year) and the next release (1.1.400) will allow the use of _typing.
• I guess we need to come up with other name instead of _typing?

[nutti]

Thank you @Andrej730 for your investigation.
Changing module name is easy but I will wait until the common convention is shown from a referenced issue.

[nutti]

@Andrej730
I think we can use our own naming convention for now.
It seems the name convention is different for each project.
How about using _typing_internal instead? Or, do you have any idea about it?

[Andrej730]

We shouldn't use a name that starts with _ as sooner or later warnings will reappear and we'll be back to this issue.

I think we have two main concerns about the name:

1. it should be somehow connected to typing
2. it shouldn't be confused with one of the actual bpy modules.

Previously we used _, so module would immediately stand out. Since we cannot use _ anymore, my current idea is to name it explicitly fake_bpy, so it will also stand out.

[nutti]

@Andrej730
Understood, but I don't want to use fake_bpy for this case because this name stands for project name itself.
How about internal instead?

[Andrej730]

I was thinking about internal or private, but they may seem like private runtime modules and they also may suggest that they are not intended to be used from the external scripts.
Maybe stub? It won't be connected to the fake bpy module, but it should be clear that this module only exists at static time.

[nutti]

Thank you for suggestion.
If possible, I would like to name this module to reflect meanings stub and internal use.
How about stub_internal?

[Andrej730]

stub_internal looks good too, if you want to emphasize that it's a special part of stubs, and it kind of is.