Skip to content

Returning Unknown instead of Any for incomplete __getattr__ #13765

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.

Sign up for GitHub

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

Jump to bottom
Closed
Avasam opened this issue Apr 2, 2025 · 1 comment · Fixed by #14030
Closed

Returning Unknown instead of Any for incomplete __getattr__ #13765

Avasam opened this issue Apr 2, 2025 · 1 comment · Fixed by #14030
Labels
project: policy Organization of the typeshed project stubs: false negative Type checkers do not report an error, but should

Comments

@Avasam
Copy link
Collaborator

Avasam commented Apr 2, 2025 •
edited
Loading

I noticed we have quite a few

def __getattr__(name: str) -> Incomplete: ...

Wouldn't it be better to write as

def __getattr__(name: str): ...  # incomplete

So that type-checkers like Pyright in strict mode can warn about unknown types ?
@Avasam Avasam added the stubs: false negative Type checkers do not report an error, but should label Apr 2, 2025
@srittau
Copy link
Collaborator

srittau commented Apr 2, 2025

I think that was a pattern mandated in CONTRIBUTING for incomplete stubs. I think the current pattern just happened via the route

  1. -> Any: ... # incomplete
  2. -> Incomplete: ... # incomplete
  3. -> Incomplete: ...

That said, I don't have a strong preference either way.

@Avasam Avasam added the project: policy Organization of the typeshed project label May 12, 2025
@Avasam Avasam mentioned this issue May 12, 2025
Merged
srittau added a commit to srittau/typeshed that referenced this issue May 12, 2025
@srittau
Replace incomplete module markers
0e4e0ad 
Closes: python#13765
@srittau srittau mentioned this issue May 12, 2025
Merged
tsibley added a commit to nextstrain/cli that referenced this issue May 23, 2025
@tsibley
dev: Fix Pyright failures with latest version (1.1.401)
5635c29 
An included typeshed stub update¹ for docutils (and many other modules)
meant that docutils.readers.standalone.Reader became an unknown type and
was duly reported as such.  We don't care.

An apparent regression² results in unnecessary "# type: …" comments in
the typeshed itself's internal code being reported as our problem.  It
is not.  Ignore them.

¹ <python/typeshed#13765>
  <python/typeshed#14030>

² <microsoft/pyright#10487>
tsibley added a commit to nextstrain/cli that referenced this issue May 23, 2025
@tsibley
dev: Fix Pyright failures with latest version (1.1.401)
1487a0d 
An included typeshed stub update¹ for docutils (and many other modules)
meant that docutils.readers.standalone.Reader became an unknown type and
was duly reported as such.  We don't care.

An apparent regression² results in unnecessary "# type: …" comments in
the typeshed itself's internal code being reported as our problem.  It
is not.  Ignore them.

Note that in this case of ignoring out-of-project source, matching an
absolute path seems to be required for the Pyright "ignore" pattern to
actually work.  (I found no relative or partial paths that work.)  Also
note that whatever globbing Pyright is doing will not match a leading
"**" to an absolute path.  Give up and anchor the pattern to an absolute
root separately for POSIX and Windows.  Yay.

¹ <python/typeshed#13765>
  <python/typeshed#14030>

² <microsoft/pyright#10487>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
project: policy Organization of the typeshed project stubs: false negative Type checkers do not report an error, but should
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Replace incomplete module markers srittau/typeshed
2 participants
@srittau @Avasam