Pylance doesn't like wrapt.ObjectProxy

[ddelange]

Hi @GrahamDumpleton,

Maintainer of smart_open here 👋

I opened an issue with pylance: microsoft/pyright#11295

And they responded this is an issue with wrapt stubs.

Any thoughts?

[GrahamDumpleton]

Entirely reasonable that stubs for the object proxy types need to be improved upon.

My main focus has been to try and get type hints into the decorators and hope people will help fix/improve them since I am far from being an expert on using type hints. Thus the object proxy types basically got ignored. I also didn't really know what I was going to have to put in them, so examples like this are a big help as it guides me on what is required.

So if you have any other examples of things that are missing do let me know.

[brianschubert]

So if you have any other examples of things that are missing do let me know.

Something you may be interested in: mypy has a tool that can help detect differences between the stubs and the runtime objects: Automatic stub testing (stubtest) - mypy documentation

Running stubtest against the current stubs reveals a number of potential discrepancies:

# Ignore errors from untyped submodules.
$ echo 'wrapt\.(__wrapt__|arguments|decorators|importer|patches|proxies|weakrefs|wrappers)\..*' > stubtest_allowlist.txt

$ uv run -w mypy -w wrapt python -m mypy.stubtest wrapt --allowlist stubtest_allowlist.txt
<snip>
Found 59 errors (checked 10 modules)

As it happens this catches the missing __enter__ method from the pyright issue:

$ uv run -w mypy -w wrapt python -m mypy.stubtest wrapt --allowlist stubtest_allowlist.txt | grep -A4 '\.__enter__'
error: wrapt.BaseObjectProxy.__enter__ is not present in stub
Stub: in file ~/.cache/uv/archive-v0/4N351-WzQKt5InXyIKzLr/lib/python3.13/site-packages/wrapt/__init__.pyi
MISSING
Runtime:
<method '__enter__' of 'ObjectProxy' objects>

[brianschubert]

Oh, and one other potential issue: right now type checkers won't treat types directly imported from submodules correctly. For example, both mypy and pyright treat wrapt.ObjectProxy and wrapt.proxies.ObjectProxy as separate types:

$ cat example.py
from typing import cast
import wrapt.proxies
compat_check: wrapt.proxies.ObjectProxy = cast(wrapt.ObjectProxy, ...)

$ uvx -w wrapt mypy --strict example.py
example.py:3: error: Incompatible types in assignment (expression has type "wrapt.ObjectProxy[Any]", variable has type "wrapt.proxies.ObjectProxy")  [assignment]
example.py:3: error: Missing type parameters for generic type "ObjectProxy"  [type-arg]
Found 2 errors in 1 file (checked 1 source file)

$ uvx -w wrapt pyright example.py 
.../example.py
  .../example.py:3:43 - error: Type "ObjectProxy[Unknown]" is not assignable to declared type "ObjectProxy"
    "ObjectProxy[Unknown]" is not assignable to "ObjectProxy" (reportAssignmentType)
1 error, 0 warnings, 0 informations

This is because having a py.typed file in the directory means that type checkers will treat all of the files in the directory as being valid sources for type information (not just the __init__.pyi stub file, which only overrides __init__.py).

If you want to hide the other submodules from type checkers, one option would be to move the __init__.pyi stub file to src/wrapt-stubs/__init__.pyi and delete src/wrapt/py.typed. That will create a separate stub-only package, which type checkers will use for type information without regard to the source *.py files.

(Another option would be to split __init__.pyi into individual stubs files for each submodule (or use inline annotations). That way type checkers would be able to correctly analyze the relationships between the various modules and their defined types. But that may be more "noise" than you want).

[GrahamDumpleton]

Thanks for extra information. Am off working on other stuff right now so wrapt is down the priority list a bit. But will see if I can get to the various issues you raised soon. Thanks.