Improve type error messages to show types instead of values

[jpfeuffer]

• Modified assertion error messages to include expected Python type
• Changed overload error to show argument types instead of values
• Added function name to overload error messages for better context

Example improvements:

• Before: 'arg my_arg wrong type'

• After: 'arg my_arg wrong type (expected list[int])'

• Before: 'can not handle type of (value1, value2)'

• After: 'can not handle types (str, list) as arguments for function myFunc()'

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Improved error messages for type checking failures, now displaying expected types in assertions
  • Enhanced overload error reporting with details about actual argument types and target function names

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Enhanced error reporting in CodeGenerator.py by propagating expected Python typing information through type checks and assertion generation. Improved assertion and overload error messages to include expected type information and actual argument types for clearer diagnostics.

Changes

Cohort / File(s)	Summary
Type checking and error reporting enhancements autowrap/CodeGenerator.py	Enhanced error reporting for type checks by propagating py_typing_type alongside existing type checks; updated assertion generation to include expected type in error messages (arg N wrong type (expected <type>)); expanded overload failure messages to include actual argument types and target function name; altered declarations of exported or public entities

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

• Key areas requiring careful attention:
  • Type information propagation through method dispatch and input conversion logic—ensure changes maintain consistency across all code paths
  • Assertion message formatting and backward compatibility—verify no breaking changes to error message parsing or logging downstream
  • Overload error handling—confirm that expanded error messages correctly capture and report actual vs. expected argument types
  • Public API changes—review alterations to exported/public entity declarations for potential impact on external consumers and documentation requirements

Poem

🐰 When types go wrong, our messages now shine bright,
With expected types shown in clear sight,
No more mystery in what went astray,
CodeGenerator speaks truth without delay!
Error messages bloom like spring's finest hay! 🌾

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: improving type error messages to display types instead of values, which aligns with the PR's core objective of enhanced error reporting.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

autowrap/CodeGenerator.py (1)

1208-1209: Improved assertion message is helpful; minor edge case consideration.

The addition of expected type information in the assertion message is a solid improvement for debugging.

One minor edge case: if expected_type ever contains a single quote character, the generated assertion string would be malformed. While standard Python type annotations don't include quotes, you could add a simple escape:

🔎 Optional defensive fix

 for n, check, expected_type in checks:
-    code.add("    assert %s, 'arg %s wrong type (expected %s)'" % (check, n, expected_type))
+    code.add("    assert %s, 'arg %s wrong type (expected %s)'" % (check, n, str(expected_type).replace("'", "\\'")))

This is a low-risk edge case, so this suggestion is optional.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3179c51 and c52e565.

📒 Files selected for processing (1)

• autowrap/CodeGenerator.py (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)

• GitHub Check: test (==3.2.0, 3.13)
• GitHub Check: test (==3.1.0, 3.12)
• GitHub Check: test (==3.2.0, 3.10)
• GitHub Check: test (==3.1.0, 3.13)
• GitHub Check: test (==3.2.0, 3.11)
• GitHub Check: test (==3.1.0, 3.10)
• GitHub Check: test (==3.2.0, 3.12)
• GitHub Check: test (==3.1.0, 3.11)

🔇 Additional comments (2)

autowrap/CodeGenerator.py (2)

991-996: Improved error message looks good.

The change correctly shows argument types instead of values and includes the function name for better diagnostics. The generated runtime code will properly format the type names.

---

1130-1130: Clean propagation of type information.

The addition of py_typing_type to the checks tuple correctly supports the improved assertion messages downstream.

[jpfeuffer]

Hmm not sure anymore. I have the feeling all these type exception are super unpythonic.
Usual python function also have no type checking. They just fail at runtime when an attribute is missing or som
It is a lot of extra code to add these type checks and also some runtime penalty for things that are called often and execute fast.
Especially for recursive types where it is also hard to get right and the error message is of limited help as it can only print the outermost type.
We also have type hints by now.

Maybe we should just remove them..
@timosachsenberg

[timosachsenberg]

hmm no strong opinion. how would it fail without them?

[jpfeuffer]

I honestly think you would get similar TypeError exceptions from cython directly. The types might be called slightly differently (maybe you get errors about cython or python c API level) and cython does not check nested types of course.

But I have never tried.

Note that for overloaded functions it gets even more tricky to check all possible combinations but there we need to do some kind of check to choose the correct overload anyway. It's probably even too simple what we are doing right now for really complex cases.

Idk what's best.