Non-aliased imported symbol not considered private

[tibdex]

Describe the bug

Pyright doesn't flag a non-aliased imported symbol as private.

To Reproduce

# sub.py (lib)
ONE = 1
TWO = 2

# __init__.py (lib)
# ONE is re-exported, TWO is not.
from .sub import ONE as ONE, TWO

THREE = ONE + TWO

Where lib has a py.typed file as described in PEP 561.

# __main__.py (app)
import lib

print(lib.ONE, lib.TWO, lib.THREE)

Expected behavior

According to:

pyright/docs/typed-libraries.md

Line 35 in cecb3e1

* Imported symbols are considered private by default. If they use the “import A as A” (a redundant module alias), “from X import A as A” (a redundant symbol alias), or “from . import A” forms, symbol “A” is not private unless the name begins with an underscore. If a file `__init__.py` uses form “from .A import X”, symbol “A” is treated likewise. If a wildcard import (of the form “from X import *”) is used, all symbols referenced by the wildcard are not private.

and this section of PEP 484:

Modules and variables imported into the stub are not considered exported from the stub unless the import uses the import ... as ... form or the equivalent from ... import ... as ... form. (UPDATE: To clarify, the intention here is that only names imported using the form X as X will be exported, i.e. the name before and after as must be the same.)

reportPrivateUsage (or another rule) should say that lib.TWO is private.

VS Code extension or command-line

Command line with this config:

[tool.pyright]
typeCheckingMode = "strict"
useLibraryCodeForTypes = true

version: 1.1.166.

Additional context

mypy 0.910 correctly reports the issue:

app/__main__.py:3: error: Module has no attribute "TWO"

[erictraut]

Thanks for the bug report. You're correct that there was a missing check. I've implemented a fix. We're going to need to take care in rolling out this bug fix because it's likely to generate new errors within some code bases.

@jakebailey, here's the PR: #2279. I plan to wait until after this week's pylance release before merging this.

[erictraut]

We've decided to add a new diagnostic rule. It's called "reportPrivateImportUsage". It will be on by default with basic type checking rules, but it can be disabled to retain the existing behavior. This will give you the ability to work around cases where the maintainers of a "py.typed" library haven't properly added redundant alias forms to indicate which imported symbols should be re-exported.

[erictraut]

This is included in pyright 1.1.168, which I just published. It will also be included in the next release of pylance.

[GBeauregard]

Is this a correct interpretation of PEP 484? It seems to be in the section for notes on stub files, and it's not clear to me why this should apply to libraries typed inline as well. Can you provide more information on your reasoning? At least some maintainers appear to believe it's a bug and the discussion therein wasn't clarified despite crosslinking here Textualize/rich#1523

[erictraut]

This applies to type stubs and py.typed libraries. For details, refer to this documentation for details. This behavior hasn't been formally specified yet in a PEP, but it is generally agreed upon by the typing community. Without this, there's no way for the author of a py.typed library to specify which symbols comprise the public interface of the library. Unlike most other modern languages, Python lacks an export keyword or similar construct.

[GBeauregard]

Thanks, this clarifies things a lot. I do sympathize with the linked maintainer, though. The symbols there are solely imported as part of an intro/demo program in __main__.py. Is it worth blocklisting __main__.py files from this check? For what it's worth mypy --strict doesn't throw any errors with that particular library so mypy may be doing something similar.