pyright strict mode raises diagnostics caused by arcade's code, not consumer code

[cspotcode]

trafficstars

Bug Report

Related to #1390

When running pyright with typeCheckingMode: strict, you get diagnostics caused by arcade's code, not the consumer's code. This requires consumers to disable certain pyright typechecking rules, which prevents consumers from leveraging those rules for their own code.

This is a broad request. Different diagnostics can be avoided in different ways, and with different levels of effort. I felt it appropriate to open a single issue to start, but this could be split into different issues, each describing a different kind of diagnostic and the changes necessary to fix it.

The example below demonstrates a reportPrivateImportUsage diagnostic.

System Info

Arcade 2.6.16
-------------
vendor: Intel
renderer: Intel(R) Iris(R) Xe Graphics
version: (4, 6)
python: 3.10.8 (tags/v3.10.8:aaaf517, Oct 11 2022, 16:50:30) [MSC v.1933 64 bit (AMD64)]
platform: win32

Actual behavior:

Code that consumes the arcade API can be typechecked with pyright's commonly-used "strict" option.

pyrightconfig.json:

{
    "include": ["src"],
    "typeCheckingMode": "strict"

example.py

import arcade
arcade.color.AERO_BLUE # <-- raises diagnostic: error: "color" is not exported from module "arcade" (reportPrivateImportUsage)

Expected behavior:

The code above should not raise a diagnostic.

Steps to reproduce/example code:

Use the pyrightconfig.json and example.py above, pip install pyright && python -m pyright

[pvcraven]

Currently running pyright with default settings results in about 1500 warnings. Changing the name of the report so that we have a task to just run through pyright cleanly.

[einarf]

I tried locally a bit a while ago and got it down to 170 errors when excluding examples and experimental. Should be doable to clean up the last stuff.

[einarf]

We are using both pyright and mypy in the project now.