There are quite a few things that broke for me relating to type hints when upgrading to any version >0.32.0, where type hint analysis was introduced: https://docs.xlwings.org/en/stable/whatsnew.html#v0-32-0-aug-13-2024

Example 1: Sub with return type None

This works:

@xw.sub
def foo():
    do_something()

But this causes an error:

@xw.sub
def foo() -> None:
    do_something()

The error happens in def write(value, rng, options, engine_name=None): in xlwings/conversion/__init__.py. This gets called with options like {"convert":NoneType}, which causes the accessor to be NoneType, which then fails when trying to do .router on it.

Example 2: Sub with argument type Iterable[str]

This works:

@xw.sub
def foo(asdf):
    do_something()

But this causes an error:

@xw.sub
def foo(asdf: Iterable[str]):
    do_something()

When passing a VBA Collection of strings from VBA to my custom sub, I always have it hinted as Iterable[str], since I don't care about the details of the Collection object, and only care about the fact that it is iterable. However, using Iterable as an argument type hint causes an error in def read(rng, value, options, engine_name=None): in xlwings/conversion/__init__.py, similar to above, where the accessor becomes the Iterable type itself instead of an Accessor class.

Suggestion to solve this and other similar examples

When accessors.get(...) does not return a subclass of Accessor, use the default accessor like in the days before v0.32.0.